What a SOC 2 Type I actually requires from a 12-person company

A SOC 2 Type I is a point-in-time attestation that your controls are designed correctly. It does not ask you to prove those controls have run reliably for months; that is Type II. For a twelve-person company chasing an enterprise deal, understanding that distinction is the difference between a ninety-day project and a self-inflicted year.

The five trust service criteria, and the one you actually need

SOC 2 covers five criteria: security, availability, processing integrity, confidentiality, and privacy. Only security is mandatory. Every well-run Type I we have shepherded scoped to security alone for the first report, then added availability or confidentiality later if a customer specifically asked. Scoping in all five on day one is the most common way small teams turn a manageable audit into an unmanageable one.

What the auditor is really checking

Underneath the framework, a Type I comes down to a handful of concrete things an auditor can see in an afternoon:

• Identity: single sign-on, multi-factor authentication, and a documented joiner-mover-leaver process.
• Access: least privilege on production systems, with a review you can show us evidence of.
• Change management: code goes to production through review, not straight from a laptop.
• Endpoints: company devices are encrypted, patched, and running protection.
• Vendors: a register of your sub-processors and the risk you have accepted for each.

Notice what is not on that list: a security team, a SIEM, penetration testing on a schedule. Those help, but a Type I does not require them, and an auditor will not fail you for their absence if your design is sound.

Type I asks whether the controls are designed well. Type II asks whether you actually run them. Do not pay for the second question before you can answer the first.

The evidence auditors accept

Evidence is where teams over-engineer. An auditor will accept a screenshot of your MFA enforcement policy, an exported list of admin group members with a date, and a short written policy signed by a named owner. You do not need a compliance platform to produce any of that, though one makes the ongoing Type II collection far easier. Buy the platform for Type II, not Type I.

What you can genuinely defer

Formal risk assessments with quantified likelihoods, a full business continuity exercise, and vendor questionnaires for every low-risk tool can wait. So can most of the availability criterion if you are not scoping it. Defer them explicitly, in writing, with a date, and auditors respect a documented decision far more than a gap you are hoping they will not notice.

The ninety-day path

A twelve-person company with a modern cloud stack can reach Type I in about ninety days: two weeks of gap assessment, six weeks of remediation, and the rest coordinating the auditor. The work that takes longest is almost never technical. It is getting one person to own each policy and sign it. Decide who that person is first, and the rest is scheduling.