How much of your SOC 2 checklist is actually required?

Where the checklist comes from

A founder showed me a platform onboarding checklist recently: about a hundred and eighty controls, each with policies to adopt and evidence tasks to wire up. The team was three people. They assumed all of it was the law of SOC 2.

Almost none of it is, at least not in the form the checklist implies. It is worth understanding the three layers, because the padding hides in the seams between them.

The criteria are the actual requirement. The AICPA's Trust Services Criteria are the yardstick a SOC 2 examination measures against. For the Security category, the one nearly every first audit should be scoped to, there are 33 of them, written at the level of principle: logical access is restricted, changes are authorized, risks are identified.

The points of focus are examples attached to each criterion, and here the AICPA is unusually plain about their status: points of focus are guidance, not all of them will be relevant to every organization, and you are not required to address every one to pass an examination. They are illustrations of how a criterion might be met, written broadly enough to cover a bank and a browser extension.

The controls are yours. You decide what your company actually does to meet each criterion, and the examiner tests whether what you claim is designed and operating. Nothing in the framework dictates their number. A three-person company can legitimately meet the criteria with a few dozen controls.

A checklist is what happens when a vendor converts the broadest reading of every point of focus into a task, for every customer, regardless of size or stack. The criteria did not demand the length. The template did.

Why templates run long

Understand the incentive and the length stops being mysterious.

For the vendor, a long checklist is all upside. It looks rigorous in a sales demo. It generates connector activity and dashboard motion, which is what a monitoring subscription is for. And it is safe: no template author ever got blamed for including too much. The costs land on you, later, as a wall of green tiles that still is not an audit.

From fieldwork, the padding has recognizable shapes. Policies for technology you do not run, adopted with one click and never read. Enterprise rituals transplanted onto tiny teams: a three-person company with a formal change advisory board, a data classification committee, a visitor badge log for an office that does not exist. The same requirement expressed as four overlapping controls because the template merged several frameworks. Controls nobody could name an owner for, because no human ever chose them.

Each of those costs you twice. Once in setup, and then forever, because every control you claim generates a permanent evidence obligation.

The audit cost of hollow controls

Here is the part the checklist never mentions: in the examination, your control list is not a wish list. It is a set of claims, and the examiner tests the claims you make.

Claim a quarterly access review committee and the examiner asks for four quarters of minutes. Claim the visitor log and someone must produce it. When the honest answer is that the control was a template artifact nobody performed, that lands in the report as an exception, a real finding generated by a fake control. I have watched companies fail testing on rituals that made no one safer, while the three controls that actually protected their customers sat underneath, working fine.

Exceptions cluster in performative controls, because performative controls are the ones with no reason to operate. An examiner would far rather see forty controls that demonstrably run than a hundred and eighty that photograph well, and so would the person reading your report.

How to trim without cutting corners

Right-sizing is not deregulation, so do it with the criteria open.

Map every control on your list to the criterion it serves. If it maps to nothing, ask what it is for. If four controls serve one criterion identically, they are probably one control wearing four names. If a control assumes a company shape you do not have, replace it with what you actually do: a solo founder's documented self-review on a calendar is a real control, and the enterprise committee version, faked, is not.

Then be honest in the other direction, because trimming has a failure mode too. Some things are genuinely load-bearing at any size: access control, offboarding, encryption, backups, logging, change discipline. Handle sensitive data and the bar rises regardless of headcount. The test is never fewer for its own sake. It is that every control you claim is one you actually perform, and every criterion is genuinely met.

The criteria are public, and shorter than you think. Read them once before you accept anyone's translation, especially a translation that happens to be priced monthly.