Why is a CPA the one who audits your security?

When I tell a founder their SOC 2 has to be signed off 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.

It is a fair reaction, and I get it a lot. Let me clear it up.

"CPA" does not mean "tax person"

People hear CPA and picture 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, meaning an outside professional examines something and issues a formal opinion others can rely on. Providing that kind of 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. Attestation just means the CPA examines your evidence and issues a formal opinion on it. The point of the report is that a customer's procurement team, security reviewer, or auditor can rely on it 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, and then put their name behind that call.

This is also who signs your SOC 2 report. It is a CPA's opinion, issued in the firm's name. Not a platform's output. Not a green checkmark on a dashboard.

The soft skills are the point

Here is what an engineer does well: confirm a setting is on. Multi-factor authentication 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 answering it is a matter of judgment.

The training that produces that judgment is specific:

• Professional skepticism. A trained habit of verifying rather than trusting. You do not take "we do quarterly access reviews" at face value. You ask to see the reviews, you check the dates, you pull a sample and inspect it.
• Independence. You have no stake in the answer being yes. That is what lets a third party lean on your conclusion.
• Sufficient appropriate evidence, written down. Inquiry, which is simply asking the company a question, does not get you there on its own. The standard requires corroboration, some independent thing that backs up the answer, and it requires you to document what you did so a reviewer can follow your steps. This is why inquiry is never enough on its own.
• The duty to be wrong on the record. If you conclude a control was 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 working under any of that.

The hard skills are the domain

None of this means SOC 2 is generic accounting. It is not. SOC 2 is the testing of internal controls across security, availability, processing integrity, confidentiality, and privacy. Doing it well takes deep, current knowledge of two things in particular. First, information security and how a real engineering org actually runs: identity and access, change management, vulnerability management, encryption, logging. Second, company governance: how risk gets owned, how a written policy turns into a practice people actually follow, who approves what. That is a specific body of expertise, and it goes stale fast if you are not living in it.

So the right practitioner holds two things at once. The assurance discipline of a CPA, and the security and governance depth to know what a good control actually looks like in production. Both, not one. With only the first you get a tidy report about systems the author does not really understand. With only the second you get a security consultant who cannot issue the opinion.

The competence is required, not optional

Here is the part that matters and almost nobody tells you. SOC 2 is a specialist examination, and the professional standards make the right competence a precondition, not a preference. A CPA may not even accept the engagement unless they have the specific competence and capabilities to perform it, and they have to apply professional competence and due care all the way through.

Read that plainly. A CPA who takes on a SOC 2 without the security, controls, and governance depth to do it properly is not following the rules. The competence is the gate, and it is enforceable. So the real question is never whether a provider is technically allowed to sign. It is whether the people doing the work actually have the depth, and a serious firm will scope itself out of work it is not built for.

Which brings us to the part that makes this vivid. Your tax CPA and a seasoned SOC 2 practitioner hold the exact same three letters and do almost nothing alike. One reads financial statements and optimizes a return. The other sets a scope, samples your terminated employees to check their access was removed, reads your identity and access configuration, walks through your change pipeline, and decides whether your access reviews actually happened. Same license. Opposite daily work. You would not want either doing the other's job, and a SOC 2 is squarely the second one's.

A CPA is also, specifically, the one who can issue the opinion, where a security consultant with a certification cannot. CISA, CISSP, and the rest are real and useful. They are not a license. 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 all cluster suspiciously in the week before the audit. You see change management that looks airtight until you sample the emergency changes. After enough of these, you build up 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 thing to watch for

The work hinges on the person. So the outcome to avoid is not knowing who yours is.

In the channel where the audit is bundled with a compliance platform, you may never meet your auditor. The economics tend to push toward assigning whoever is cheapest and most available, who may or may not have the domain depth your stack needs. None of that is an accusation about any one firm. It is the shape of the incentives. 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 actually perform the work and stand behind it, and verify they are a qualified, licensed CPA. The license is public. Look it up.

The real question, then, is never whether a CPA belongs in a security audit. It is whether the specific people in front of you have the security, controls, and governance competence the work demands, and whether you can see who they are. That you can check.