How Should a Company Prepare for a SOC 2 Audit?
Preparing for a SOC 2 audit takes 8 to 12 weeks of structured readiness work across eight domains. You need to define your scope, document policies that match how you actually operate, and establish controls across access management, change management, monitoring, data protection, vendor oversight, and incident response. Before the formal examination begins, run a pre-audit readiness assessment to find and fix gaps on your own timeline — that single step saves more time and money than any other preparation activity.
On This Page
- Step 1: Define scope and select your tools
- Step 2: Write policies that reflect reality
- Step 3: Lock down access control
- Step 4: Implement change management controls
- Step 5: Set up monitoring and logging
- Step 6: Protect your data
- Step 7: Manage your vendors
- Step 8: Complete training and prepare incident response
- Step 9: Run a pre-audit readiness assessment
- The SOC 2 readiness checklist
- The readiness timeline
- Five gaps auditors find most often in startups
- Frequently Asked Questions
Step 1: Define scope and select your tools
The first decision in a SOC 2 readiness program is which Trust Services Criteria (TSC) to include. Security, known as the Common Criteria, is required in every report. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional. Most companies start with Security alone and add criteria only when a buyer or contract requires them. Alongside scope, you need to choose your auditor — a licensed certified public accountant (CPA) firm — and a compliance automation platform to manage evidence collection.
Getting these two decisions right at the start shapes the cost and timeline for everything that follows.
- Security (Common Criteria) — required in every SOC 2 report; the right starting point for nearly all companies
- Availability — adds uptime and resilience commitments; relevant when customers depend on your system around the clock
- Processing Integrity — covers whether your system delivers complete, accurate, and timely results; relevant for financial and data processing platforms
- Confidentiality — covers how sensitive information is protected; relevant when you handle confidential business data
- Privacy — covers collection, use, retention, and disposal of personal information; relevant for consumer-facing products
For your auditor, look for a firm with experience at your stage and in your industry. Large national accounting firms carry larger price tags; boutique firms that specialize in SOC 2 for software companies often move faster and communicate more clearly with technical teams. For your compliance automation platform, look for one that integrates with your existing infrastructure — your cloud provider, identity provider, and code repository — to pull evidence automatically rather than requiring your team to gather it manually.
Step 2: Write policies that reflect reality
Auditors expect a documented policy set that matches what you actually do. A policy that describes aspirational practices — the way you intend to operate someday — will create findings when auditors test whether the controls it describes are actually in place. Every policy needs a named owner who is responsible for keeping it current and an annual review date. Getting this right early means your controls and your documentation tell the same story.
The core policy set for a SOC 2 scoped to the Security criteria typically includes:
- Information security policy — the governing document that sets overall security commitments and assigns accountability
- Access control policy — how access is granted, reviewed, and revoked
- Change management policy — how changes to production systems are reviewed and approved
- Incident response policy — how security incidents are identified, escalated, and resolved
- Data classification policy — how data is categorized and what handling rules apply to each tier
- Acceptable use policy — how employees may use company systems and data
- Vendor management policy — how third-party service providers are evaluated and monitored
- Risk assessment policy — how the company identifies and addresses security risks
Each policy should be written in plain language, assigned a named owner, and linked to the specific controls that implement it. Auditors will check that the policies you have documented are the ones your team actually follows.
Step 3: Lock down access control
Access control is one of the highest-scrutiny areas in a SOC 2 audit. Auditors will test whether multifactor authentication (MFA) is enforced across key systems, whether access is provisioned at the level of least privilege, whether access is reviewed on a regular schedule, and whether access is promptly removed when employees leave. Weaknesses here are among the five most common findings in startup audits.
The controls auditors look for most consistently are:
- Multifactor authentication — enforce it everywhere it is available: cloud infrastructure, source code repositories, identity providers, and administrative consoles
- Least-privilege access — provision access by role, not by individual preference, and avoid standing administrative access to production systems
- Quarterly access reviews — schedule formal reviews of who has access to what, and document the outcome; ad hoc reviews do not satisfy this control
- Offboarding procedures — access should be removed on the day of departure or before; document the process and keep evidence of completion
Before your audit, pull a full list of users with access to each key system. If you cannot generate that list quickly, that is itself a gap worth addressing.
Step 4: Implement change management controls
Change management controls give auditors confidence that changes to your systems are reviewed, tested, and traceable. The essential controls are a peer code review requirement before merging, maintained separation between your development and production environments, and documented records for every production change. These controls work together to reduce the risk that an unreviewed change introduces a security or availability problem.
What auditors test in change management:
- Peer review before merge — code review should be required, not optional, and enforced through your source control platform rather than relying on team norms
- Separate environments — development, staging, and production should be isolated; developers should not have standing write access to production
- Documented change records — your issue tracker, pull requests, and deployment logs together create the audit trail; make sure they are linked and retained
- Rollback capability — auditors will want to see that production changes can be reversed if a problem is detected
Step 5: Set up monitoring and logging
Monitoring and logging controls demonstrate that your company detects security events rather than simply preventing them. Auditors look for centralized log collection from key systems, alerts configured for meaningful security events, and defined retention periods. A company that cannot show it would detect a significant security event cannot demonstrate active security posture.
The monitoring program auditors expect to see:
- Centralized log collection — aggregate logs from your cloud infrastructure, identity provider, and production systems into a single destination
- Alerts on meaningful events — define and configure alerts for events like failed authentication spikes, privilege escalation, and unusual access patterns; document what each alert means and who responds
- Defined retention periods — know how long logs are retained and make sure that period covers your audit window
- Evidence of review — auditors may ask for documentation showing that alerts have been reviewed and acted on during the audit period
Step 6: Protect your data
Data protection controls cover how you handle the data your customers entrust to you. The three pillars are encryption in transit and at rest, a current sensitive data inventory, and regularly tested backup restoration. The last point is the one most teams neglect: a backup you have never restored is a hope, not a control.
Data protection controls to have in place before the audit:
- Encryption in transit — enforce HTTPS/TLS for all external communications and for internal service-to-service communication where sensitive data moves
- Encryption at rest — encrypt databases, object storage, and backups; document which encryption standard is in use
- Sensitive data inventory — maintain a current map of where sensitive data is stored, processed, and transmitted; auditors will test this against your actual architecture
- Tested backup restoration — run and document a backup restoration test before the audit; a successful restore test is the only evidence that your backup program works
Step 7: Manage your vendors
SOC 2 requires you to demonstrate that third-party service providers who handle your data or support your operations are managed with appropriate rigor. The practical requirements are a current subprocessor list, a documented process for reviewing vendor security before onboarding, and data protection agreements in place with vendors who handle customer data.
Vendor management controls auditors test:
- Current subprocessor list — maintain a list of third-party services that process customer data; review it at least annually and update it when vendors change
- Vendor security review — document how you evaluate a vendor's security posture before onboarding; a review of their SOC 2 report or security questionnaire qualifies
- Data protection agreements — confirm that data processing agreements or business associate agreements are in place with applicable vendors; keep copies
Many startups manage vendors informally through individual relationships. If your subprocessor list lives in someone's head rather than a document, start there.
Step 8: Complete training and prepare incident response
Auditors expect evidence that your team has completed security awareness training and that your incident response program has been exercised — not just written. Documented training completion records and a tabletop exercise before the audit window demonstrate an active security culture rather than a compliance exercise on paper.
Training and incident response requirements:
- Security awareness training — all employees should complete training at least annually; record completion dates and keep evidence; include coverage of phishing, acceptable use, and data handling
- Acceptable use acknowledgment — collect signed or electronically recorded acknowledgments of your acceptable use policy from all staff
- Incident response plan with defined roles — the plan should name who is responsible for detection, containment, communication, and recovery; generic documents without named roles do not satisfy this control
- Tabletop exercise — test the plan with a structured tabletop exercise before the audit; document the scenario, participants, findings, and any improvements made
Step 9: Run a pre-audit readiness assessment
A readiness assessment is a structured gap analysis conducted before the formal audit begins. An experienced reviewer maps your current controls against the Trust Services Criteria you are pursuing, identifies gaps and control weaknesses, and prioritizes remediation. This is the highest-value step in the preparation sequence because it lets you fix problems on your own schedule rather than discovering them when the auditor is already in fieldwork. Companies that skip this step often spend more in remediation costs and audit fees than the assessment would have cost.
A readiness assessment typically produces a prioritized gap report organized by Trust Services Criteria, a remediation roadmap with time estimates, and documentation guidance for controls that are operationally in place but not yet written down. The output gives you a clear picture of what remains before you are audit-ready and how long each item will take.
Running the assessment 8 to 10 weeks before your planned audit start date leaves enough time to close most gaps without rushing.
The SOC 2 readiness checklist
The table below summarizes the key controls in each domain and what auditors look for. Use it as a self-assessment before engaging an auditor or readiness partner.
| Domain | Key controls | What auditors look for |
|---|---|---|
| Scope & governance | Criteria selected; auditor and platform chosen; risk assessment completed | Defined system boundaries; documented risk register with owner |
| Policies | Core policy set documented; named owners; annual review dates | Policies match actual practices; evidence of review |
| Access control | MFA enforced; least-privilege provisioning; quarterly access reviews; offboarding process | Evidence of review completion; no orphaned accounts; MFA active on key systems |
| Change management | Peer review enforced; separate environments; documented change records | Pull request history; no direct production pushes without review |
| Monitoring & logging | Centralized log collection; configured alerts; defined retention | Logs from key systems; evidence alerts were reviewed and acted on |
| Data protection | Encryption in transit and at rest; sensitive data inventory; tested backups | Encryption in place; documented restore test with results |
| Vendor management | Current subprocessor list; vendor security reviews; data protection agreements | Evidence of review; agreements on file; list current |
| Training & incident response | Training completion records; IR plan with named roles; tabletop exercise completed | Training records for all staff; tabletop documentation |
The SOC 2 readiness timeline
Most growing SaaS companies can reach audit-ready status in 8 to 12 weeks. The timeline depends heavily on where your controls stand at the start. Companies with engineering maturity and existing security practices can move through readiness faster; those building controls largely from scratch typically need the full 12 weeks. For a Type II report, add the observation window — typically three to six months — before the auditor completes fieldwork.
| Phase | Typical duration | Key activities |
|---|---|---|
| Scope and kick-off | Week 1 to 2 | Select criteria, define system boundary, choose auditor and platform |
| Gap assessment | Week 2 to 4 | Map current controls against criteria, identify gaps, prioritize remediation |
| Remediation | Week 4 to 10 | Write policies, implement controls, complete training, run tabletop |
| Evidence collection | Week 8 to 12 | Gather and organize evidence; finalize documentation |
| Type I audit | Shortly after readiness | Point-in-time examination; auditor issues report |
| Type II observation window | Three to six months | Controls operate and evidence accumulates |
| Type II fieldwork and report | A few weeks | Auditor tests and issues the Type II report |
Starting readiness before a buyer demands it is the clearest advantage you can give yourself. Companies that begin the process in response to a live deal negotiation are almost always working against an artificial deadline.
Five gaps auditors find most often in startups
Most first-time SOC 2 findings cluster around the same five issues. They are not obscure technical failures — they are straightforward controls that got deferred because the company was focused on growth. Knowing them in advance lets you close them before the auditor arrives.
| Gap | Why it happens | How to close it |
|---|---|---|
| MFA not enforced on key systems | MFA was enabled but not required; exceptions accumulated over time | Audit current MFA enforcement; remove exceptions; enforce via identity provider policy |
| Access reviews skipped | Access reviews were scheduled but not completed or not documented | Complete a formal access review before the audit window; document results and any access removed |
| Backups never tested | Backups run automatically and were assumed to work | Run and document a restore test; schedule quarterly tests going forward |
| Incident response plan untested | A plan was written but never exercised | Run a tabletop exercise with leadership and document the outcome before the audit |
| Policies misaligned with practice | Policies were copied from templates without being adapted to how the company actually works | Review each policy against current operations; update to match reality, then maintain with annual reviews |
Frequently Asked Questions
How long does it take to prepare for a SOC 2 audit?
Most growing SaaS companies can reach audit-ready status in 8 to 12 weeks with the right guidance. The timeline depends on how mature your controls already are. Companies with little existing documentation typically need the full 12 weeks; those with a more mature security program can move faster.
What policies do I need for SOC 2?
You need a documented policy set covering information security, access control, change management, incident response, data classification, acceptable use, and vendor management. Each policy needs a named owner and an annual review cycle. Auditors expect policies to reflect what you actually do, not aspirational goals.
Do I need a compliance automation tool to get SOC 2?
You are not required to use one, but most teams find that a compliance automation platform significantly reduces the internal hours spent collecting and organizing evidence. Without automation, evidence collection is largely manual and error-prone. The platform cost is usually recovered quickly in saved engineering time.
What is a SOC 2 readiness assessment?
A readiness assessment is a structured gap analysis that identifies which controls are in place, which are missing, and which need to be strengthened before a formal audit. Running one before the auditor arrives is the highest-value preparation step because it lets you remediate gaps on your own timeline rather than discovering them during fieldwork.
What are the most common SOC 2 audit failures for startups?
The five gaps auditors find most often are: multifactor authentication not enforced on key systems, access reviews that were skipped, backups that were never tested, an incident response plan that exists on paper but has never been exercised, and policies that describe aspirational practices rather than actual ones.
Can a startup prepare for SOC 2 without external help?
Yes, but expect roughly 300 to 450 internal hours on a first attempt without prior experience, usually spread across engineering and operations. With expert guidance, that drops to about 110 to 180 hours because the heavy lifting shifts off your team and rework largely disappears.
Where to go from here
If you are ready to start, the most useful first step is understanding where your controls stand today. Read our guides on what SOC 2 is and the difference between Type I and Type II and how much a SOC 2 audit costs and how long it takes. If you are comparing frameworks, see our explainer on choosing between SOC 2 and ISO 27001. For a broader view of compliance as a growth asset, see investor-ready compliance for tech startups.
