How to Become SOC 2 Compliant: Step-by-Step for Small Business (2026)

This article provides general educational information about SOC 2. It is not legal or compliance advice. Businesses pursuing SOC 2 should work with a licensed CPA firm and qualified compliance professionals.

Before the Steps: What This Process Actually Looks Like

SOC 2 compliance for a small business typically takes 6–18 months from the decision to pursue it to receiving a Type 2 report. The range is wide because it depends almost entirely on how much of your security infrastructure already exists.

A company with centrally managed endpoints, documented policies, MFA enforced on all systems, a functional patch management programme, and existing vendor agreements can move through the process in 6–9 months. A company starting from scratch — no formal policies, no MDM, inconsistent access management, no patch visibility — takes 12–18 months because it’s building the controls and running the observation period simultaneously.

This guide assumes you’ve read our companion article — What Is SOC 2 Compliance? A Plain-English Guide for SMBs — and understand the basics. If not, read that first. This article is the operational playbook: what to do, in what order, and what evidence you’ll need to produce.

The process in eight steps:

1. Define your scope and select Trust Services Criteria
2. Conduct a gap analysis
3. Assign ownership and build a programme plan
4. Implement and document security controls
5. Select a compliance automation platform (if using one)
6. Select and engage a CPA firm auditor
7. Pursue SOC 2 Type 1 (optional but recommended)
8. Run the Type 2 observation period and complete the audit

Step 1: Define Your Scope and Select Trust Services Criteria

Timeline: 1–2 weeks

The scope defines which systems, services, and processes are included in the audit. Getting scope right is the most important decision you make before starting — too broad, and you multiply complexity and cost; too narrow, and enterprise buyers may find the report inadequate.

What to include in scope:

Your scope should cover the systems that process, store, or transmit customer data as part of your primary service offering. For a SaaS company, this is typically your production cloud environment (AWS, Azure, or GCP), your identity and access management systems, your code repositories, and the key third-party services your product depends on.

Do not include everything your company uses. Employee laptops are in scope because they provide access to production systems. The coffee machine is not. The HR payroll system may or may not be in scope depending on whether it processes customer data.

A practical scoping approach:

Write down your primary service. Ask: what systems does that service depend on? Which systems store or process customer data as part of delivering it? Those systems are in scope. Systems that support internal operations but don’t touch customer data are generally out of scope.

Selecting Trust Services Criteria:

Start with Security (mandatory for all SOC 2 audits). Then evaluate:

• Availability: Are you making uptime commitments to customers? Do you have contractual SLAs? If yes, add Availability.
• Confidentiality: Do you handle data customers have specifically designated as confidential? Legal, financial, or healthcare data subject to confidentiality agreements? If yes, consider adding Confidentiality.
• Processing Integrity: Are you processing financial transactions, payroll, or other data where accuracy is a contractual requirement? If yes, consider Processing Integrity.
• Privacy: Are you making specific privacy commitments beyond basic data protection? If yes, consider Privacy.

For most small SaaS businesses and service providers: start with Security only, or Security plus Availability. Every additional criterion adds controls, evidence requirements, and audit cost. Add criteria when specific customer requirements demand them.

Step 2: Conduct a Gap Analysis

Timeline: 2–6 weeks

A gap analysis compares your current controls against the SOC 2 Trust Services Criteria requirements. The output is a list of what you have, what’s missing, and what needs improvement — before an auditor finds it.

The most frequently identified gaps across first-time SOC 2 programs are consistent enough to serve as your starting checklist. Expect to find most of these in a small business environment:

Access controls:

• No formal access review process (quarterly is the standard cadence auditors expect)
• Active accounts remaining for former employees — this appears as a critical finding in virtually every first-time audit
• MFA not enforced on all production systems and cloud consoles
• No documented provisioning and deprovisioning process with defined timelines (access revocation within 24 hours of termination is a common standard)
• Excessive permissions — developers with production database admin rights they don’t need for day-to-day work

Policies and documentation:

• No formal written information security policy
• No written incident response plan (or one that exists but has never been tested — auditors treat an untested plan as equivalent to no plan)
• No written change management policy or documented approval records for system changes
• No written risk assessment process or risk register

Vendor management:

• No Data Processing Agreements (DPAs) with cloud and SaaS vendors
• No formal vendor risk assessment process
• No inventory of which vendors process customer data on your behalf

Technical controls:

• No centralised endpoint management (MDM) on employee devices
• No vulnerability scanning or patch management programme
• No centralised logging or security event monitoring

Security awareness:

• No documented security training programme with completion records
• No phishing simulation history

Incident response:

• Incident response plan exists only as a document, never tested or updated

You do not need to hire a consultant to conduct a gap analysis, though doing so is valuable for a first-time program. A structured internal assessment using the AICPA’s published Trust Services Criteria as your checklist is a legitimate starting point. Many compliance automation platforms (Vanta, Drata, Secureframe) provide a readiness dashboard that surfaces gaps automatically once integrated with your systems — which is one of their primary value propositions.

Step 3: Assign Ownership and Build a Programme Plan

Timeline: 1–2 weeks (concurrent with gap analysis)

SOC 2 requires a named owner for each control — someone responsible for ensuring the control exists, operates correctly, and evidence is collected. Without ownership, controls exist on paper but nobody is responsible for them when something breaks.

Assign a compliance lead. For a small business, this is typically the CTO, Head of Engineering, or a senior technical person. This person is accountable for the overall programme — not responsible for every control, but accountable for the programme running. In a 10–20 person company, the compliance lead is often managing this alongside other responsibilities; budget 25–40% of one person’s time for the first 6 months.

Map controls to owners. For each gap identified in Step 2, assign a specific person as the control owner. Access management controls belong to whoever manages your identity provider. Endpoint management controls belong to whoever manages IT. Incident response belongs to the compliance lead or engineering leadership. Vendor management belongs to whoever manages contracts.

Build a remediation timeline. For each gap, estimate how long it will take to implement or remediate, what resources or budget it requires, and what dependencies exist. Sequence the work so foundational infrastructure (MDM, logging, patch management) is in place before dependent controls (access reviews that require MDM data, incident response runbooks that reference your logging tools).

Set your audit target date. Work backward from when you need the report. If a customer deal requires a Type 2 report in 18 months, your observation period (minimum 6 months) must start at month 6 or earlier. Your control implementation must be complete before the observation period starts.

Step 4: Implement and Document Security Controls

Timeline: 8–16 weeks depending on starting point

This is the substantive work. The specific controls required depend on your gap analysis, but the following represent the core implementation requirements for a Security-criterion SOC 2 for most small businesses.

Access Management

What auditors need to see: Evidence that access is managed systematically — provisioned when people join, reviewed quarterly, and revoked promptly when people leave.

Set up and document a formal onboarding process that includes provisioning access to required systems with manager or compliance lead approval. Set up and document an offboarding process that revokes access within 24 hours of departure from every in-scope system. Run your first formal access review: list every person with access to every in-scope system and verify that access is appropriate for their role. Document the review and its findings. Schedule quarterly repeats.

Enforce MFA on every in-scope system at the organisation level — in your identity provider (Google Workspace, Microsoft Entra ID, Okta) and your cloud provider (AWS, Azure, GCP) — not optionally per user.

Endpoint Management

What auditors need to see: Evidence that all employee devices accessing in-scope systems are managed, encrypted, and covered by security policies.

Deploy an MDM or endpoint management solution across all employee devices. Jamf for Mac-heavy organisations, Microsoft Intune for Windows/mixed environments, Kandji as an alternative Mac option. Configure policies requiring full-disk encryption, screen lock, and endpoint protection. The compliance platform you choose will typically integrate with your MDM to automatically collect enrollment and policy compliance evidence.

Vulnerability Management and Patching

What auditors need to see: Evidence that you scan for vulnerabilities, assess their severity, and patch within defined timelines (critical patches within 30 days is a common standard).

Deploy a vulnerability scanner across your production infrastructure (AWS Inspector, Qualys, or Tenable are common for cloud environments). Implement patch management software for employee devices. Document a written vulnerability management policy defining scanning frequency and patch timelines. Run your first vulnerability scan and document findings and remediation.

Logging and Monitoring

What auditors need to see: Evidence that you collect security logs from in-scope systems and review them.

Enable CloudTrail (AWS) or equivalent cloud audit logging. Enable logging in your identity provider. Configure alerting for key security events: failed login attempts, MFA disabled, new admin accounts created, unusual data access. Document who reviews alerts and at what frequency. For a small company, a weekly log review record is adequate evidence.

Incident Response

What auditors need to see: A written, documented incident response plan and evidence that it has been tested.

Write an incident response plan covering detection, containment, eradication, recovery, and post-incident review. Include specific roles, communication procedures, and escalation paths. Conduct a tabletop exercise — a structured walkthrough of a hypothetical incident scenario with your team. Document that the exercise occurred, who participated, and what was identified. An untested IR plan generates audit findings. A tested plan, even a simple tabletop exercise, does not.

Change Management

What auditors need to see: Evidence that changes to production systems go through a defined review and approval process.

Establish a documented change management policy. For a small engineering team, this means no direct pushes to production without a code review approval in version control, infrastructure changes approved before deployment, and records of who approved what change. Your existing PR and code review history in GitHub is valid evidence if the process is documented and consistently followed.

Written Policies

Write policies for each major control area, reviewed annually, acknowledged by employees. The core policies required:

• Information Security Policy (master policy)
• Acceptable Use Policy
• Access Control Policy
• Incident Response Plan
• Change Management Policy
• Vulnerability Management Policy
• Data Classification and Retention Policy
• Vendor Risk Management Policy

Compliance platforms provide policy templates. Use them as starting points, but customise them for your actual environment. Auditors can identify when policies describe controls your company doesn’t actually operate.

Vendor Management

Create a vendor inventory listing every service that processes customer data on your behalf. Obtain and file a DPA for each. For major vendors (cloud provider, identity provider, payment processor), conduct and document a risk assessment — reviewing their SOC 2 report, security certifications, and any relevant audit findings.

Security Awareness Training

Deploy a security awareness training platform (KnowBe4, Wizer, or similar). Assign onboarding training to all employees. Assign annual refresher training. Run monthly phishing simulations. Export completion records for audit evidence.

Step 5: Select a Compliance Automation Platform (If Using One)

Timeline: 1–2 weeks to select; 1–2 weeks to configure

For a company with 15+ employees and a cloud-native production environment: use a platform. The $7,500–$15,000/year cost is recovered in the 100–200 hours of manual evidence collection it replaces over a Type 1 cycle.

For a company with fewer than 10 employees and a simple environment: manual evidence collection with a well-organised spreadsheet tracker is possible.

The four main options:

Vanta ($10,000–$15,000/year for smaller companies): strongest for first-time SOC 2, fastest time to audit-ready, 400+ integrations. Best if speed is the priority.

Drata (similar pricing, slightly higher median): stronger for multi-framework programmes and scaling companies. Better if you plan to run SOC 2 alongside ISO 27001 or HIPAA.

Secureframe ($8,000–$20,000/year): competitive pricing, good AWS integration, solid for budget-constrained SMBs.

Sprinto ($5,000–$15,000/year): popular with early-stage companies, simpler setup, lower entry cost.

All four connect to your cloud provider, identity provider, MDM, HR system, and code repositories. The functional difference between any of them on a first SOC 2 engagement is small. Select based on budget, integration coverage for your technology stack, and partner auditor network pricing.

Start the platform subscription when you begin control implementation — not months earlier.

Step 6: Select and Engage a CPA Firm Auditor

Timeline: 2–4 weeks to select; ongoing through audit

Only a licensed CPA firm registered with the AICPA can issue a SOC 2 report. Auditor fee ranges for small businesses in 2026:

• Type 1 audit: approximately $8,000–$18,000 for boutique SOC 2 specialist firms
• Type 2 audit: approximately $15,000–$35,000 for most small businesses
• Big 4 firms: $75,000+ and only warranted for IPO-track companies or when buyers specifically require it

Get quotes from 2–3 auditors. Your compliance platform’s partner network is a useful starting point — partner firms may offer 10–25% discounts and have experience with the platform’s evidence format. You are not obligated to use a partner firm.

When comparing auditors, ask for: estimated fee for Type 1 and Type 2 at your company size, expected timeline from engagement to report, and what information they need during fieldwork.

Engage your auditor before your controls are fully implemented — auditors are often booked 6–12 weeks out. Sharing your gap analysis with prospective auditors during selection allows more accurate quotes.

Step 7: Pursue SOC 2 Type 1 (Recommended)

Timeline: 4–8 weeks for the audit itself, after controls are implemented

A Type 1 audit validates your control design before the observation period begins and produces a report you can share with prospects while the Type 2 observation period runs. A Type 1 report plus a statement that your Type 2 observation period is underway is often sufficient to unblock deals waiting on compliance evidence.

The Type 1 audit process:

Your auditor requests evidence for each in-scope control. Expect to provide policy documents, access review records, MFA configuration screenshots, MDM enrollment evidence, vulnerability scan results, training completion records, vendor DPAs, and system architecture documentation. The auditor reviews evidence, may ask questions, and issues a report assessing whether controls are suitably designed. Address any exceptions before starting the observation period.

Start your Type 2 observation period concurrently. Your controls should be operational before the Type 1 audit anyway — start the observation period clock immediately. This allows you to have a Type 2 report approximately 9–12 months after starting the programme rather than 12–18 months.

Step 8: Run the Type 2 Observation Period and Complete the Audit

Timeline: 6–12 months observation + 4–8 weeks audit

The observation period cannot be accelerated. Your controls must operate for a minimum of 6 months, with 12 months producing the most credible report.

What happens during the observation period:

Controls run consistently. Access reviews happen quarterly. Patches are applied within defined timelines. Vulnerability scans are conducted. Incidents are documented in the IR register. Change management approvals are logged. Security training is completed and recorded.

Your compliance platform monitors controls continuously and flags drift. Address drift promptly — auditors sample across the full observation window, and gaps in the evidence record generate findings.

The most common Type 2 finding: Controls operated inconsistently, not that controls were never implemented. If access reviews only happened twice instead of quarterly, that’s a finding. If patch deployment logs show a 60-day gap, that’s a finding. The observation period requires consistent operation and consistent evidence, not just initial setup.

The Type 2 audit:

The auditor conducts fieldwork reviewing evidence collected during the observation period. Fieldwork typically takes 4–8 weeks for a small company. The report is either:

• Unqualified (clean) opinion: No material exceptions found. This is the goal.
• Qualified opinion: Exceptions noted. The report describes specific control failures. Minor exceptions are manageable with a clear management response; material exceptions may require remediation evidence before enterprise clients proceed.

The Evidence Checklist: What Auditors Typically Request

Access Management:

• Access review records (quarterly, documented findings)
• Offboarding process records showing timely access revocation
• User provisioning records with manager approval
• MFA enforcement configuration from all in-scope systems
• Privileged access inventory

Endpoint Management:

• MDM enrollment report covering all employee devices
• Device encryption status report
• Endpoint protection deployment status

Vulnerability Management:

• Vulnerability scan reports from the observation period
• Patch deployment records showing remediation within defined timelines
• Written vulnerability management policy

Change Management:

• Code review and PR approval records
• Written change management policy
• Infrastructure change approval records

Incident Response:

• Written incident response plan
• Tabletop exercise record
• Incident register

Security Awareness:

• Training completion records for all employees
• Phishing simulation campaign records

Vendor Management:

• Vendor inventory listing all processors of customer data
• DPAs for each in-scope vendor
• Risk assessment records for key vendors

Logging and Monitoring:

• Cloud audit logging configuration
• Evidence of log review activity during the observation period
• Security alerting configuration

Policies:

• All core policies listed in Step 4, with annual review dates and employee acknowledgment records

Risk Assessment:

• Annual risk assessment documentation
• Risk register with identified risks, ratings, and treatment decisions

Timeline Summary: First SOC 2 Type 2 from Start to Report

What to Avoid

Don’t start the observation period before controls are fully operational. The auditor tests the full observation window. Starting before access reviews are running, before MDM is deployed, or before logging is enabled means early portions of the window generate evidence gaps.

Don’t leave access reviews until the audit approaches. Quarterly reviews must happen throughout the observation period. There is no way to conduct a Q1 access review in Q4. Missing scheduled reviews generate findings that cannot be remediated retroactively.

Don’t accept generic policy templates unchanged. Read and customise them for your actual environment. A policy describing controls you don’t operate is worse than having no policy — it documents a gap between your stated controls and your actual practice.

Don’t neglect the observation period once controls are set up. Qualified opinions most commonly result from inconsistent operation, not missing controls. Access reviews missed one quarter, patches undeployed for 60 days, a vendor’s DPA expired — these are the findings that a well-run programme prevents and a neglected one generates.

Final Verdict: The Right Mindset for This Process

SOC 2 is a compliance programme, not a compliance project. Your first Type 2 report is not the conclusion — it’s the beginning of an annual renewal cycle.

The businesses that find SOC 2 manageable in subsequent years built real security infrastructure in year one and treat the audit as verification of ongoing operations rather than a preparation sprint. Build controls that are operationally sustainable: quarterly access reviews that take 30 minutes because your MDM provides the data automatically, continuous monitoring that alerts you to drift rather than quarterly manual checks.

Build it properly once. Run it consistently. The enterprise deals that follow are the reward.

Frequently Asked Questions

Can a small business complete SOC 2 without a consultant?

Yes. SOC 2 does not require a consultant — you can conduct your own gap analysis, implement controls, use a compliance automation platform, and work directly with a CPA auditor. What is non-negotiable is the CPA firm, which must issue the report. A consultant adds value by identifying gaps you might miss and accelerating timeline, particularly for a first-time programme. Formal readiness engagements from compliance consultancies typically cost $10,000–$25,000. Whether that’s worth it depends on your internal expertise and team bandwidth.

What is the most commonly missed SOC 2 control in first-time audits?

Active accounts belonging to former employees. This finding appears in virtually every first-time SOC 2 audit for small businesses. Companies grow quickly, people leave, and access removal isn’t always systematic. Auditors sample a set of terminated employees and verify that access was revoked promptly. Implement a documented offboarding process with a specific timeline for access revocation (24 hours is the common standard) and apply it consistently from day one of your programme.

How do I know if my Type 2 observation period has started?

Your observation period starts when your controls begin operating — when your access review process is active, MDM is deployed and monitoring devices, logging is running, and your other controls are in place. There is no formal “start” declaration; the auditor will examine the evidence record and test from the earliest point where consistent operation can be demonstrated. Coordinate with your auditor on the proposed observation period start and end dates so both parties have aligned expectations.

How much internal time does SOC 2 require?

For a 15–30 person company pursuing a first Type 2: approximately 200–400 hours of internal time across the full engagement. This includes gap analysis, control implementation, policy writing, evidence organisation, responding to auditor questions, and ongoing monthly administration during the observation period. The compliance lead will typically spend 25–40% of their time on SOC 2 during the active implementation phase, tapering to 5–10% during the observation period. Year two requires substantially less time — typically 50–60% of year one — as controls are already in place and evidence collection is automated through the compliance platform.

What if I need a SOC 2 report faster than 12 months?

The observation period cannot be shortened below 6 months. For a faster path to a report you can share with prospects, pursue Type 1 as quickly as possible — 3–4 months from decision to Type 1 report is achievable for a technically prepared company. Begin the observation period immediately and run it concurrently. You will have a Type 1 report to share with prospects during the observation period, followed by a Type 2 report at the 9–12 month mark. For deals that specifically require Type 2, communicate your timeline honestly — most enterprise procurement teams will accept a Type 1 report plus a committed Type 2 delivery date when the vendor is clearly mid-programme rather than not started.

This article provides general educational information about the SOC 2 compliance process. It does not constitute compliance or legal advice. Businesses pursuing SOC 2 should engage a licensed CPA firm and qualified compliance professionals. The AICPA publishes the official Trust Services Criteria at aicpa-cima.com.

Related reading on SmallBiz Defense:

• What Is SOC 2 Compliance? A Plain-English Guide for SMBs (2026)
• GDPR Compliance Checklist for Small Business Owners (2026)
• Security Awareness Training for Small Business: KnowBe4 vs Proofpoint vs Cofense (2026)