Is SOC 2 a Certification or an Attestation? (And Why It Matters)

Search "SOC 2 certification" and you'll get millions of results, including plenty from vendors who should know better. Here's the uncomfortable truth for anyone starting this process: there is no such thing as SOC 2 certification. SOC 2 is an attestation, not a certification, and the difference isn't just semantics. It affects what you're actually buying, who's allowed to issue it, and what your customers' security teams expect to see when they open the document.

That said, we still say "SOC 2 certification" in this article's title, and you'll hear it from prospects, procurement teams, and even some auditors. Buyers search that way, so it's worth meeting people where they are. But if you're the one signing a contract with an auditor or explaining your compliance posture to an enterprise customer, you need to understand what you're actually getting.

Certification vs. attestation: what's the actual difference

A certification is a pass or fail judgment against a fixed standard. An accredited certification body examines your organization, confirms you meet every requirement in the standard, and issues a certificate that says so. ISO 27001 works this way. So does PCI DSS, in its own fashion. There's a checklist, a threshold, and a binary outcome.

An attestation is different. A licensed CPA firm examines your controls and issues an opinion on whether those controls were suitably designed (and, for a Type II report, operating effectively) to meet the criteria you selected from the AICPA's Trust Services Criteria. There's no pass or fail badge. There's a detailed report, typically 30 to 100+ pages, describing your systems, your controls, the auditor's testing procedures, and their findings, including any exceptions.

SOC 2 falls firmly in the second category. It's governed by the AICPA (the American Institute of Certified Public Accountants), and only licensed CPA firms can perform the audit and issue the report. There is no accreditation body handing out SOC 2 certificates the way there is for ISO 27001. If a vendor tells you they're "SOC 2 certified" and hands you a badge instead of a report, that's worth a follow-up question.

Why the report format matters more than the label

Because SOC 2 is an attestation, the deliverable is a report, not a certificate. That report has real substance:

• Management's description of the system. How your infrastructure, people, and processes actually work.
• The auditor's opinion. Unqualified (clean), qualified (with caveats), or adverse.
• The controls tested and results. Every control mapped to the Trust Services Criteria you selected, with pass or exception noted.
• Type I vs. Type II. Type I is a point-in-time snapshot. Type II covers a window, usually 3 to 12 months, and confirms controls actually operated as designed over that period. Most enterprise buyers want Type II.

This is why SOC 2 reports are typically shared under NDA rather than posted publicly like a certificate would be. They contain a level of detail about your internal controls that most companies don't want indexed by Google. When a customer's security team asks for your SOC 2, they expect the full report, not a summary page or a logo you're allowed to put on your website.

Why the vocabulary trips people up

Part of the confusion comes from how SOC 2 gets marketed. Compliance automation platforms, some auditors, and plenty of well-meaning marketing teams use "SOC 2 certified" as shorthand because it's what people search for and it sounds more concrete than "attestation." It's not malicious, but it can set the wrong expectations early in a sales cycle, especially with enterprise buyers whose security or procurement teams know the difference and will notice the mismatch the moment they ask for documentation. If you're preparing for SOC 2 as a founder or CTO, this matters practically. You're not working toward a pass/fail exam. You're building a system of controls, evidence, and documentation that a CPA firm will examine and opine on. The scope of criteria you select (Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional), the audit period you choose, and the auditor you hire all shape what that final report says. There's more judgment and negotiation involved than the word "certification" implies.

Do not read "no pass or fail badge" as "you cannot fail," which is the mistake this distinction most often causes. An adverse opinion and a disclaimer are both real outcomes that get written into real reports, and a qualified opinion prints your exceptions for every buyer who opens the document. The more common outcome for a company that arrives unprepared is worse than any of them: the firm reaches fieldwork, finds the evidence is not there in a testable form, and recommends pausing. You have then paid for an audit that produced nothing you can send a customer, and re-entering fieldwork means paying a firm again. What a stalled audit actually costs covers the arithmetic.

What to say instead

If precision matters to you (and it should, especially when talking to security-savvy buyers), use phrases like "we have a SOC 2 Type II report," "we underwent a SOC 2 audit," or "we're SOC 2 attested." Save "SOC 2 certified" for casual conversation or marketing copy aimed at people who search that term, and be ready to explain the distinction when a technical buyer asks. Getting this right from day one also shapes how you scope the engagement. Our SOC 2 compliance consulting work starts by walking founders and CTOs through exactly what the audit produces, what evidence it requires, and how to avoid the common trap of treating it like a certification checklist instead of a genuine, ongoing control environment. If your team is also weighing broader security posture alongside the audit itself, our security advisory services cover that ground too.

The bottom line

SOC 2 is an attestation, delivered as a detailed report from a licensed CPA firm, not a certificate from an accreditation body. That distinction affects what your sales team can claim, what your customers will ask to see, and how you should scope the work internally. Get the vocabulary right early and you'll avoid awkward conversations with security-literate buyers later.

Not sure where your organization stands on SOC 2 readiness, or which Trust Services Criteria actually apply to you? Get in touch with traztech and we'll walk through your specific situation, no generic checklist required.

Who is allowed to sign the report, and how to check

Because the deliverable is an attestation, the identity of the firm signing it carries weight that a certificate number never would. The report has to be issued by a CPA firm licensed in a US state or a Canadian province, and that firm has to be enrolled in a peer review program covering attestation engagements. Peer review is the closest thing SOC 2 has to accreditation, and it is checkable. In the United States you can look a firm up in the AICPA peer review public file. In Canada, provincial CPA bodies maintain their own registers of firms permitted to perform assurance work. Ten minutes of checking before you sign a statement of work is worth more than any logo on the firm's website.

This matters commercially, not just procedurally. We have watched security reviewers at large buyers refuse a report because the issuing firm could not be found in any register, and refuse another because the signing partner's licence had lapsed between fieldwork and issuance. The buyer is not being difficult. Their own auditors will eventually ask them how they satisfied themselves that a vendor report was reliable, and "we accepted a PDF" is not an answer that survives that conversation.

The independence rules bite too. A CPA firm that designed and implemented your control environment cannot then attest to it. That is the whole reason readiness work and the audit itself sit with different parties. If a single vendor offers to write your policies, configure your evidence collection and then issue your opinion, either the independence problem is being ignored or the opinion is being issued by a separate entity you have not been introduced to. Ask which one it is, in writing.

The window problem, and what a bridge letter does

A Type II report covers a defined observation window, say 1 January to 30 June. It says nothing about July onward. Buyers doing diligence in October are looking at a document whose coverage stopped four months earlier, and mature procurement teams notice immediately. This is the single most common practical surprise for founders who assumed the report was a badge that stays valid for a year.

The standard patch is a bridge letter, sometimes called a gap letter. It is a short document signed by your management, not by the auditor, stating that no material changes to the control environment occurred between the end of the observation window and the date of the letter, and disclosing anything that did change. It is an assertion by you, which is exactly why some buyers treat it as thin. A bridge letter can reasonably cover a gap of about three months. Stretched to six or more, sophisticated reviewers start asking for a fresh report instead, and you have lost the argument.

The scheduling implication is worth planning around. If your renewal cycle produces a report every twelve months but your biggest deals close in the last quarter of your fiscal year, you want the observation window to end shortly before that quarter, not shortly after it. Choosing the window is one of the few genuinely strategic decisions in the whole program, and most companies make it by accident based on whenever they happened to sign the audit engagement.

The sections buyers actually read

Nobody in procurement reads a hundred pages. They read the opinion paragraph, they skim the exceptions, and then they go to two sections that founders often do not know exist.

Complementary user entity controls. These are the things your report says your customers must do for your controls to work. Enforcing SSO on their side, managing their own admin accounts, configuring retention. A reviewer reads this list to work out what obligations your product pushes back onto them. A CUEC list that is vague or absurdly long reads as a company offloading its responsibilities, and it generates follow-up questions that delay the deal. Write these deliberately with your auditor rather than accepting boilerplate.

Subservice organizations, carved out or included. Your report has to deal with the providers that sit underneath you, most obviously your cloud host. The carve-out method excludes their controls from your scope and says the reader should look at the provider's own report. The inclusive method pulls them into yours, which in practice is almost never available to a startup because it requires the subservice provider to participate. Carve-out is normal and expected. What is not expected is a report that carves out something the buyer considers core to your service, such as a managed database vendor holding all customer records, without addressing how you monitor that provider. That monitoring is your control, and it needs to be tested.

What an exception looks like in print, and how to talk about it

An exception is not a failure notice. It is a line in the testing tables saying that for a given control, the auditor selected a sample and found instances where the control did not operate. Three of forty access reviews were completed late. Two terminated employees kept their accounts for eleven days. One change went to production without a recorded approval.

Most first-year Type II reports have at least one. The reports that survive buyer review are the ones where each exception is accompanied by a management response that names the root cause, the remediation, and the date it was fixed. The reports that create problems are the ones where the exception sits there unexplained, or where the management response is a paragraph of reassurance with no dates in it. If you are handed a draft report, that response section is yours to write and it is worth a serious afternoon.

The pattern of exceptions matters more than the count. A single missed access review reads as an operational slip. Exceptions spread across access management, change management and monitoring read as an organization that stood up controls for the audit and did not run them. Reviewers are reasonably good at telling those two apart, and only one of them gets a follow-up call rather than a rejection.

What actually drives the cost

Founders benchmark audit fees against each other and get wildly different numbers, because the fee is driven by things that rarely appear in the quote. The number of Trust Services Criteria you selected beyond Security. The number of distinct systems and environments in scope. Whether you have one production region or four. Headcount, because population sizes for sampling scale with people. Whether your evidence arrives as clean exports or as screenshots someone took by hand.

The readiness side has its own drivers, and they are more predictable. Teams that already run change management through pull requests with required reviewers, already provision access through an identity provider, and already keep an asset inventory, need documentation and a handful of gaps closed. Teams where production access is a shared root credential and deployments happen from a laptop need engineering work before any of the documentation means anything. That is the actual variable, and it is why a fixed-price readiness engagement should always start with a gap analysis rather than a proposal.

There is a second-order cost most people miss: how well documented your readiness position is when the audit firm quotes you. A firm pricing an unknown environment prices in its own risk. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, which we wrote up in our auditor vetting case study.

When you should not buy SOC 2 readiness from us

There are several situations where hiring us is the wrong call and we will say so on the first call.

You have one prospect asking, and they have not committed. If a single mid-market buyer mentioned SOC 2 in passing, ask them directly what they need to approve you. Often the honest answer is a completed security questionnaire, a recent penetration test and evidence of MFA and encryption. That package costs a fraction of an audit and can be assembled in weeks. Buy the report when the pipeline justifies it, not when one deal mentions it.

Your buyers are European or your business is UK-based. ISO 27001 is the currency in those markets and a SOC 2 report often has to be explained rather than accepted. If your revenue is concentrated there, start with ISO 27001 and add SOC 2 later if North American demand appears.

You are pre-product or pre-first-customer. A Type II report attests to controls operating over a period. If your architecture is going to change substantially in the next six months, you will be attesting to a system that no longer exists. Spend the money on the engineering that makes the controls cheap to run later.

You already have a competent internal owner. If someone on your team has run a SOC 2 before and has the bandwidth, they do not need us to hold the pen. What they usually want is a second opinion on scope and a review of the auditor's engagement letter, which is a few hours of advisory rather than a program. Our free traztech Workspace gives that person the control register and evidence tracking without an engagement attached to it, and there is no obligation to buy anything alongside it.

Questions worth asking an audit firm before you sign

The engagement letter is negotiable and most first-time buyers do not treat it that way. Ask who performs the fieldwork and whether it is subcontracted. Ask how many hours of your team's time the firm expects to consume and in what form. Ask what happens, contractually and financially, if the firm reaches fieldwork and concludes you are not ready, because that clause decides who absorbs the cost of a stall. Ask whether the fee covers one round of report revisions or bills them separately. Ask for a redacted sample report so you can see the writing quality your buyers will be reading.

Ask, finally, how the firm handles the second year. Renewal pricing that is quiet in year one and steep in year three is common. If you want that whole cycle handled as an ongoing program rather than an annual scramble, that is what our continuous compliance retainers exist for, and the arithmetic only works if you are genuinely going to be audited every year.