InackGuardWho this guide is for
This guide is for founders, engineering leads and first security hires at small software companies whose customers have started asking for a SOC 2 report. It explains what the report is, which policies and controls to put in place first, what evidence to collect and when, the common gaps in small teams, and a realistic plan for the first ninety days. It does not replace an auditor's advice, but it should help you arrive at the first auditor conversation prepared, with a clear scope and a credible timeline.
What SOC 2 is, briefly
A SOC 2 report is an independent auditor's opinion on how a service organisation manages security and, optionally, availability, confidentiality, processing integrity and privacy. Enterprise buyers ask for it because it saves them auditing you themselves.
A Type I report looks at whether controls are designed properly at a point in time. A Type II report looks at whether they operated over a period, usually three to twelve months.
Write these policies first
Start collecting evidence now
Type II audits look back over time. Start keeping evidence before you engage an auditor: access review sign-offs, pull-request approvals, incident tickets, training records, backup test results and vendor reviews. Automate collection where you can.
Common gaps in small companies
A realistic path
Write the policies, run them for a few months, close the obvious gaps, then do a readiness assessment before choosing an auditor. Be honest with customers about where you are; many will accept a plan and a date.
A worked example
A twelve-person software company sells to a bank that asks for SOC 2. It has no report. It writes its core policies in two weeks, starts quarterly access reviews and requires reviewed pull requests for every change, tests a backup restore and runs a tabletop incident exercise. Three months later it has evidence of operation, completes a readiness assessment, and engages an auditor for a Type I, followed by a six-month Type II window. It tells the bank the plan and the dates, and the bank signs with a contract clause requiring the Type II report within a year.
Evidence to automate
Checklist
A deeper look: choosing the scope
Scope is the set of systems, people and processes the report covers. Too broad and the audit becomes expensive; too narrow and customers will not find it useful. Start with the production system customers use and the processes that support it: access, change, monitoring, incident response and vendors.
Most companies start with the security criteria only and add availability or confidentiality later if customers ask.
A deeper look: tools and evidence
You do not need expensive software to start, but you do need discipline. A shared drive with clear folders, a ticketing system for access and change requests, and your code host's review history can provide most early evidence. Automation tools help as you grow by collecting evidence continuously and flagging gaps.
Questions people ask
How long does it take? A first Type I can follow a few months of preparation. A Type II needs an observation period, often three to six months for a first report.
How much does it cost? It depends on scope, auditor and tooling. Get several quotes and ask what is included.
What do we tell customers in the meantime? Share your policies, a readiness summary, and a dated plan. Many buyers accept that, with a contract clause.
Should we buy compliance software first? Not necessarily. Software helps collect evidence, but it cannot write your policies or run your controls. Start with clear ownership, written policies and a few months of operating them; then choose tools that remove manual effort from the evidence you already collect. That order avoids paying for features you are not ready to use.
Keeping it going
SOC 2 is not a one-off. Controls must operate every day, evidence must keep flowing, and the report renews each period. Assign owners for each control area and review them monthly.
A 90-day starter plan
Weeks 1 to 2: agree the scope and criteria, name a control owner for each area, and write or adopt the core policies.
Weeks 3 to 4: tighten access. Remove shared accounts, enforce multi-factor authentication, document joiner and leaver steps, and run the first access review.
Weeks 5 to 6: require reviewed changes for code and configuration, and keep the history. Set up basic monitoring and alerting for production.
Weeks 7 to 8: write and test the incident response plan with a tabletop exercise. Test a backup restore and record the result.
Weeks 9 to 10: review your key vendors and keep their reports and agreements on file. Run security awareness training and record completion.
Weeks 11 to 12: do a readiness review against the criteria, close gaps, and speak to auditors about timing and scope.
Keep collecting evidence throughout. By the end, you will have the policies, the habits and the first months of evidence an auditor will look for, and a credible date to give customers.
Key terms
Summary
SOC 2 is achievable for a small company if you treat it as a set of habits rather than a document. Agree a sensible scope, write the core policies, and then follow them: access reviews, reviewed changes, monitoring, incident response, backups and vendor reviews. Start collecting evidence early, because a Type II report looks back over a period of operation. Use simple tools at first and add automation as you grow. Be open with customers about where you are and when you expect a report; many will accept a credible plan backed by policies and early evidence. Once you have a report, keep the controls running every day, because the next period starts immediately. The companies that pass easily are those that made the controls part of normal work.