SOC 1 descends from the old SAS 70 and lives under SSAE 18: management defines control objectives around the processing it performs — transactions are authorized, calculations are accurate, output is complete — and an independent auditor attests to them. The audience is narrow by design. Your customers’ own financial-statement auditors read it to decide whether they can rely on your systems instead of testing around them. It is not a security report, even though IT general controls appear inside it.
If errors in your service could misstate a customer’s books — you run payroll, process payments or insurance claims, administer funds, calculate billing — expect SOC 1 requests from controllers and their audit firms. Most SaaS companies get asked for SOC 2 instead, because their buyers care about data protection rather than ledger accuracy; platforms that sit in the money path often end up carrying both reports side by side. When a prospect asks for “your SOC,” pin down which one before quoting a timeline — the two audits share mechanics, not scope. Our SOC 2 guide covers the report most software companies actually need.
Like its sibling, a SOC 1 engagement comes in Type 1 and Type 2 forms — design at a date versus operation across a period, the same split described under SOC 2 Type 1 — is restricted-use, and ends in the same opinion language, unqualified when clean. What changes is the yardstick: management’s own control objectives stand in for the Trust Services Criteria.
