A customer's security team asked for your SOC 2 report. You don't have one yet, the compliance platform is half set up, and somebody has to pick an auditor.
Probably you.
Pick carefully, because the auditor is the part your customer sees. Their security team reads the auditor's name and the test descriptions in your report. They never see your compliance dashboard.
I run soc2auditors.org, an independent directory of SOC 2 audit firms. Just this year, I’ve read more than 500 requests from companies looking for a SOC 2 auditor and helped them compare quotes.
These are the checks I’d run on any firm before signing its engagement letter, the audit contract.
Two are public lookups that take a few minutes. The other three are questions to ask the firm.
TL;DR
- Get the legal name of the CPA firm that will sign.
- Check its licence in CPAverify or with the state board.
- Read its latest peer review in the AICPA public file, and note the date.
- Ask how it tailors testing to your systems and how it samples.
- Ask who built your controls and how the audit team stays separate.
- Confirm the report type, period and scope against your customer's request.
Step zero: find out who actually signs
A SOC 2 report is an examination report with an auditor's opinion in it. It isn't a certificate. For a US engagement, it has to come from a licensed CPA practice.
The company selling you the audit may not be that practice. Compliance platforms and consultancies often sell the audit while an affiliated CPA firm does the examination and signs the report. That's a normal setup. It just means the name on your proposal may not be the name you need to check.
So get the legal name of the signing firm first. It's in the engagement letter, and it's on the opinion letter of any report the firm has issued.
If a proposal promises you'll be "SOC 2 certified", ask what you'll actually receive. The answer should be a report with an opinion in it.
If the firm is outside the US, ask where it's authorized to practice and which standards it will report under. Then confirm both with the relevant professional body.
Check 1: the licence
Search the signing firm in CPAverify, NASBA's lookup. On the Firm tab, pick the state where the signing firm is licensed (usually its home office) and type the firm name. You're looking for an active licence under the same name as your engagement letter. If the result is unclear, ask that state's board of accountancy.
Licensing, AICPA membership and peer review are separate records kept in separate places. Check each one.
Check 2: peer review
CPA firms enrolled in the AICPA's peer review program get reviewed by other CPAs once every three years. The public file always shows whether a firm is enrolled. It shows the review itself only for firms in certain AICPA sections or firms that chose to publish it.
Search the legal name, then any trade name, in the AICPA Peer Review Public File. A firm that issues SOC 2 reports should have a System Review, and it ends in one of three ratings:
- Pass. The reviewer found the firm's quality system is designed and run well enough to give reasonable assurance that its work meets professional standards.
- Pass with deficiencies. The same, except for the problems the report lists.
- Fail. The reviewer found significant deficiencies in that system.
Three things trip people up.
A Pass is a conclusion about the firm's system, based on a sample of its work. It doesn't vouch for your report.
No documents in the public file is an unknown, not a Fail. Ask the firm for its latest peer review report and its letter of response. A firm can share them with you if it chooses. A firm that isn't in the file at all, or shows as not enrolled, is a different case. For a US firm issuing SOC 2 reports, ask why before you go further.
The date matters. Reviews come around every three years, so a review year that ended long ago needs an explanation.
And if you find a Pass with deficiencies, read what the deficiency was. One in the firm's SOC work bears on your report. One in an unrelated part of the practice bears on it less.
Check 3: ask how they'll test your systems
This one changed in May 2026. The AICPA told its peer reviewers that looking at a single SOC 2 file is often not enough, and asked them to look at a firm's use of outside SOC platforms, whether its engagement timelines are reasonable, and whether each engagement is tailored to the client.
Engagements that come out identical across clients because nothing was tailored can be judged nonconforming, which means not performed in line with professional standards. The Journal of Accountancy has the details. Its February piece on "fast and easy" audits is the background.
You can see the difference in the report itself. Take a change management control: "code changes are reviewed and approved before deployment". Here are two ways an auditor might describe testing it. Both are made up.
Inquired of the engineering lead and inspected the change management policy.
or
Obtained the 1,312 pull requests merged to the main branch of the production repository in GitHub during the period, selected 40, and inspected each for an approving review by someone other than the author before merge.
The first could describe any company. Asking staff and reading a policy can’t show the control worked across the period. The second names your systems, the population and the sample.
A security reviewer at your customer can tell the difference, and so can the AICPA’s peer reviewers. They’re now told to look for firms whose test descriptions read the same for every client.
Before you sign, ask the firm how it tailors its risk assessment to your system and how it picks samples. When the draft report arrives, check that the test descriptions name your tools.
Check 4: ask who built your controls
The firm that audits your controls can’t be the firm that designed them. Under the AICPA’s independence rules, designing or maintaining a client’s internal control is a management responsibility, and a firm that takes one on isn’t independent, whatever safeguards it adds. Other work, like a readiness assessment or a pen test, can sit next to the audit if you keep the decisions and the firm can show how it protects its independence. Ask how.
If a package bundles readiness work, policy writing or a pen test with the audit, ask who signs the report and how the audit team is kept apart from the people who did the other work. Get the answer in writing.
Check 5: match the scope to what your customer asked for
Reread your customer's request. Most ask for a Type 2, which tests whether your controls worked over a period, usually three to twelve months. A Type 1 looks only at design, on a single date. Confirm which one they need and what period they'll accept.
Two parts of the scope tend to land on engineering.
The first is your cloud provider. Almost every startup's report uses the carve-out method for AWS, GCP or Azure: the report names the provider and lists the controls you rely on it for, but doesn't test them. Your customers can read the provider's own SOC 2 report for that part.
The second is complementary user entity controls. Your report will likely list things your customers must do for your controls to work, like enforcing SSO in your product or removing their own leavers. Engineering often ends up drafting that list, so find out early when the auditor wants it.
And then there's timing. A report dated soon after the period ends proves nothing on its own, and no AICPA rule sets a minimum gap. But peer reviewers are now told to look at timelines. A firm that promises your Type 2 report days after the period closes should be able to tell you when the testing happens.
If you've been through an audit, what did your auditor ask engineering for that you didn't expect? I'd like to hear it.
Top comments (0)