The request usually arrives in the middle of a deal: the customer’s security team wants a SOC 2 report. For a company of thirty or forty people with no security hire, it can feel like being asked for a document that takes a year and a department to produce.
What SOC 2 actually is
A SOC 2 report is an attestation by a licensed CPA firm on your controls, measured against the AICPA’s Trust Services Criteria. Security is always in scope; availability, processing integrity, confidentiality and privacy are optional. A Type I report looks at whether controls are designed properly at one point in time. A Type II looks at whether they actually operated over a period, usually between three and twelve months.
Only a CPA firm can issue the report. Anyone else offering to “give you SOC 2” is selling preparation, software, or something worse.
Choose criteria your customers care about
The most common early mistake is scoping every criterion because it seems thorough. Each one adds controls, evidence and audit cost. Start with Security, add Confidentiality if customers are sending you their data, and add the others when a customer actually asks.
“Most of SOC 2 is proving habits you already have. The rest is the list of things you were going to fix anyway.”
Turn habits into evidence
Good engineering teams already do much of what SOC 2 asks: code review before merge, separate environments, on-call rotations, onboarding and offboarding. What is usually missing is the evidence — a record that the review happened, that access was removed on the day someone left, that someone looked at the access list this quarter.
Wherever possible, collect that evidence automatically from systems you already use, rather than building a parallel world of spreadsheets that drifts out of date by the second month.
Related engagement Ready for the auditor before the auditor arrived →The gaps that come up every time
Periodic access reviews for production systems. Customer data copied into staging without the same protections. Administrative actions that are not logged. Vendor and sub-processor reviews. Security training that nobody tracks. None is difficult on its own; all of them are much easier to fix before the audit window opens than during it.
Run a mock audit
A few weeks before the real examination, have someone independent walk through the controls as an auditor would, asking for evidence. It is the cheapest way to turn an exception in your report into a fix nobody else ever sees.