Most teams pick a SOC 2 auditor the way they pick any vendor: three proposals, a call with each, and a decision on price and start date. That works until the report reaches a buyer's security team and they ask who issued it, or until fieldwork starts and the firm's process turns out to fit your systems badly.
The firm you choose signs the opinion your customers rely on. It also sets how much of your team's time the audit consumes. This article covers what to check before you sign an engagement letter, the questions that separate one proposal from another, and the warning signs worth walking away from.
Who is allowed to issue a SOC 2 report
A SOC 2 report is an attestation engagement performed under the AICPA's attestation standards. Examination engagements like SOC 2 fall under AT-C section 205, and the AICPA publishes a guide specifically for SOC 2 examinations. The report is issued by a CPA firm, and the opinion is signed by that firm.
This rules out a category of provider that sometimes appears in searches: a consultancy that offers "SOC 2 certification" itself. SOC 2 is not a certification, and nobody certifies you against it. A firm that describes its output that way either does not issue the report or is describing it loosely. Either is worth a direct question.
Check licensing and peer review
Two things are verifiable before any sales call.
Licensing. CPA firms are licensed by state boards of accountancy. Ask which state licenses the firm, and check that board's public lookup.
Peer review. Firms that perform attestation engagements are generally required to undergo peer review under the AICPA's peer review program. A peer review is an external review of the firm's own quality control. Ask for the most recent peer review report and its rating. A "pass" is what you want to see. A "pass with deficiencies" or "fail" deserves an explanation.
Neither check tells you the firm is good. Both tell you it is a firm whose reports will not be questioned on basic standing.
Independence: the line between help and audit
Your auditor must be independent of you. Under the AICPA's independence rules, a firm cannot audit controls it designed, implemented, or operates on your behalf. Performing management functions for an attest client impairs independence.
This matters most when the same firm offers both readiness work and the audit. Some firms do readiness assessments for clients they later audit, within limits their independence policies set. Others keep the two strictly separate, and refer readiness work elsewhere. Neither model is wrong. What you need is a clear answer to three questions:
If you do our readiness assessment, what will you not do, so that you can still audit us?
Will the people who advise us also test our controls?
Who in your firm decides whether a piece of advice would impair independence?
A firm that answers vaguely is telling you something. A firm that offers to write your policies and then audit them is telling you more. If you want a readiness assessment first, what one should cover is in what a SOC 2 readiness assessment should cover.
Who does the work, and how
The proposal names the firm. The work is done by people, and they are the variable that matters most to your team's experience.
Ask about the team
Who signs the report. The engagement partner or principal is accountable for the opinion. Ask how involved they are during fieldwork, not only at sign-off.
Who performs the testing. Some firms use their own staff throughout. Others use delivery teams elsewhere, or contractors. This is common and not a problem in itself. Ask who your day-to-day contact will be, and whether that person stays for the whole engagement.
Continuity into year two. A team that already understands your system asks fewer repeat questions. Ask whether the firm aims to keep the same team.
Ask about the process
How a firm collects evidence decides how many hours your engineers spend on the audit. Ask to see the request list format, and how evidence is submitted.
Can they accept system-generated exports and read-only access, or do they expect screenshots for everything?
How do they handle a sample request: one list up front, or rolling requests during fieldwork?
When they find a possible exception, do they raise it with you before the draft report, so you can provide context or missing evidence?
How long, typically, from the end of your observation period to report issuance?
The exception question is the one that matters most. A firm that surfaces issues early gives you a chance to correct a misunderstanding. A firm that reveals them in the draft gives you a fight over wording. For how fieldwork should run once you have chosen, working well with your auditor covers the relationship side.
Fit with your systems and your buyers
A firm that audits mostly on-premises environments may be perfectly competent and still slow on a cloud-native stack. Ask how many of their current SOC 2 clients run on infrastructure like yours, and what that infrastructure is. You are not asking for client names. You are asking whether your architecture will be new to them.
Then ask about your buyers. If you sell to regulated enterprises, your customers' third-party risk teams will read the report closely. A firm that regularly writes reports for companies selling into those buyers knows what those reviewers look for in the system description and the test descriptions.
Two more fit questions are worth asking:
Categories beyond security. If you plan to add availability, confidentiality, or privacy later, ask whether the firm tests those regularly.
Other frameworks. If ISO 27001 certification is on your roadmap, note that certification is issued by an accredited certification body, not by a CPA firm acting as a SOC auditor. Some firms have an affiliated certification body. Ask whether audits can share evidence requests, and how they keep the two engagements distinct.
Reading the proposal
Proposals look similar until you put them side by side. Compare these points.
| Item | What to look for |
|---|---|
| Scope | The categories, the system, and the period named explicitly |
| Report type | Type I or Type II stated, with the period dates for a Type II |
| Fee structure | Fixed fee, or estimate with the conditions that change it |
| Out-of-scope work | What triggers additional fees: scope changes, delays, extra locations |
| Timeline | Fieldwork window and expected report delivery after period end |
| Bridge letters | Whether the firm supports them, and how. Bridge letters are typically issued by management, not the auditor |
| Tooling | Whether you must use their portal, and whether it accepts direct exports |
If you are still deciding between report types, SOC 2 Type I vs Type II covers the trade-off. The proposal should match the decision you have already made. It should not make it for you.
Warning signs
Some patterns justify ending the conversation.
A guaranteed clean opinion. No independent auditor can promise the outcome of testing that has not happened.
A fixed price with no defined scope. Either the scope is assumed, and you will learn the assumptions later, or the testing will be thin.
An offer to build and audit your controls. That is the independence problem stated as a feature.
Pressure to start the observation period immediately. Your readiness, not the firm's calendar, should set the start date. Starting before controls operate produces exceptions you then have to explain for a year.
Reluctance to share a peer review report. It is a reasonable request, and a firm in good standing can answer it.
How TrustLynce helps
TrustLynce keeps your controls, evidence, and auditor requests in one place, so whichever firm you choose works from the same record. The auditor portal gives your auditor a room for requests and findings, and the SOC 2 framework page shows how controls map to the criteria. If you want help preparing before the engagement, our services include audit readiness support.