Why is a CPA the one who audits your security?

When I tell a founder their SOC 2 has to be signed by a CPA, the reaction is almost always the same. Wait. An accountant is doing my security audit? My engineers know our infrastructure cold. Why is the tax guy involved.

Fair reaction. Let me clear it up.

"CPA" does not mean "tax person"

People hear CPA and think 1040s and quarterly filings. That is one corner of the profession. A SOC 2 is not accounting work at all. It is an assurance engagement, and independent assurance is the thing the CPA profession was actually built to do.

The AICPA's SOC for Service Organizations suite, which includes SOC 1, SOC 2, and SOC 3, is a CPA attestation service. It produces a report a customer's procurement team, security reviewer, or auditor can rely on without redoing the work themselves. That reliance is the whole product. And reliance is only worth something if the person providing it is independent, skeptical, and accountable.

So the CPA is not in the room because they know your Kubernetes setup best. Your engineers win that contest every time. The CPA is in the room because they are trained and licensed to look at your evidence and decide whether it actually supports the claim, then put their license behind that call.

This is also who signs your SOC 2 report. It is a CPA's opinion. Not a platform's output. Not a dashboard.

The soft skills are the point

Here is what an engineer does well: confirm a setting is on. MFA enforced, encryption at rest enabled, the access list pulled. True facts, easy to read.

Here is what the audit is actually asking: does that setting prove the control operated the entire period, for everyone in scope, with no quiet exceptions. That is a different question, and it is a judgment.

The training that produces that judgment is specific:

• Professional skepticism. A trained default to verify rather than trust. You do not take "we do quarterly access reviews" at face value. You ask to see the reviews, you check the dates, you sample.
• Independence. You have no stake in the answer being yes. That is what lets a third party lean on your conclusion.
• Sufficient appropriate evidence, documented. Inquiry alone does not get there. The standard requires corroboration, and it requires you to write down what you did so a reviewer can follow it. This is why inquiry is never enough on its own.
• The duty to be wrong on the record. If you call a control as operating effectively and it was not, that is your name, your license, your problem.

Those are taught, examined, and enforced under a code of conduct. An engineer confirming a config is not operating under any of that.

The hard skills are the domain

None of the above means SOC 2 is generic accounting. It is not. SOC 2 is internal-controls testing over security, availability, processing integrity, confidentiality, and privacy. IT general controls, access management, change management, governance, risk. Deep, specific domain work.

So the right practitioner has two things at once. The assurance discipline of a CPA, and the technical depth to know what good controls actually look like in a real engineering org. Both. Not one.

The refinement most founders miss

Here is the part that matters and almost nobody tells you. There is no separate "SOC 2 license." Technically, any licensed CPA firm can sign one.

That sounds like a loophole. It is not, and the reason is in the standards.

So a reputable CPA will not take SOC 2 work they are not trained for, because the rules forbid it. The mechanism is competence, not a special certificate.

Which brings us to the vivid part. Your tax CPA holds the exact same three letters as a seasoned SOC 2 practitioner. Same license. Completely different animal. Different training, different fieldwork, different competence. A SOC 2 specialist who has never filed a corporate return and a tax CPA who has never tested an access-review control are both, technically, CPAs. You would not want either doing the other's job.

And a CPA, specifically, is the one who issues the opinion rather than a security consultant with a cert. CISA, CISSP, and the rest are real and useful. They are not licensure. They do not carry the independence requirement, the attestation standards, or the authority to issue the opinion.

Why fieldwork is the multiplier

Reading the standard once teaches you the rules. It does not teach you judgment.

Judgment comes from years across many companies, watching the same controls pass on paper and fail in practice. You see the access review that was "done quarterly" but the dates cluster suspiciously the week before the audit. You see change management that looks airtight until you sample the emergency changes. After enough of these, you develop pattern memory. You know where to push.

That is the difference between someone who can recite the criteria and someone who can find what a first-time audit actually finds.

So here is the real risk to you

The work hinges on the person. Which means the worst outcome is not knowing who yours is.

In the bundled-platform channel, you may never meet your auditor. The economics push toward assigning whoever is cheapest and most available, who may or may not have the domain depth your stack needs. The value was never the firm's logo on the cover. It was the named, qualified person and their track record.

So before you sign anything, do the one thing that protects you. Find out exactly who will sign, and verify they are a qualified, licensed CPA. The license is public. Look it up.

The good version of this is not hard to picture. A CPA with the right competence, whose name and experience you can actually see, doing a real audit, affordably, right inside the AI tool you already work in. If you want to talk through what that looks like for your company, book a call.