What Is SOC 2? A Plain-Language Guide (2026)

If a customer, prospect, or investor has asked you for "SOC 2 certification," you're not alone in wondering exactly what that means. The term gets thrown around loosely, and most of what shows up in a quick search is either vendor marketing or auditor jargon. Here's the plain-language version.

What SOC 2 actually is

SOC 2 is not a certification in the strict sense, even though almost everyone, including your customers, will call it that. It's an attestation: an independent CPA firm examines your company's controls and issues a report stating whether those controls meet a defined standard. There's no badge you earn once and keep forever. There's a report, produced by an accountant, that describes how your systems and processes actually work.

The standard behind it comes from the AICPA (the American Institute of Certified Public Accountants) and is built around five Trust Services Criteria:

• Security (mandatory for every SOC 2 report)
• Availability
• Processing Integrity
• Confidentiality
• Privacy

Security is the only criterion every company must include. It covers the basics enterprise buyers care about most: access controls, encryption, monitoring, incident response, and vendor management. The other four are optional and depend on what your product does. A SaaS company handling health data might add Confidentiality and Privacy. A company where uptime is the product might add Availability. Most B2B SaaS companies start and stay with Security alone, often called a "Security-only" SOC 2.

Who actually needs it

SOC 2 shows up most often as a sales blocker, not a legal requirement. There's no law that says you need it. But if you sell into mid-market or enterprise customers, especially in the United States, procurement and security teams will ask for it before they'll sign, and in a lot of deals that request arrives with a deadline attached. It's also increasingly expected in fintech, healthtech, and any B2B software touching customer data, regardless of company size.

If you're a founder or CTO fielding a security questionnaire for the first time, or you've had a deal stall because a customer's vendor risk team wants a report you don't have, that's usually the signal it's time to start. Waiting until the deal is signed and the clock is already running is the most common and most expensive mistake we see.

What the process involves

At a high level, getting to a SOC 2 report involves three phases:

• Readiness. You document your policies, put controls in place (access reviews, logging, encryption, vendor risk management, incident response, and so on), and close the gaps between what you actually do and what the standard requires. This is where most of the real work happens.
• The audit. An independent CPA firm tests your controls and produces the report. This has to be a licensed CPA firm; it can't be the same company that helped you build your controls, because that would compromise their independence.
• Ongoing operation. SOC 2 isn't a one-time event. A Type II report covers a period of time, typically three to twelve months, during which your controls have to actually be operating, not just written down. Maintaining the report means keeping those controls running year over year.

A quick note on report types: a Type I report confirms your controls are designed correctly as of a single point in time. A Type II report confirms they operated effectively over a period of months. Most enterprise buyers want Type II. Type I can be useful as an early proof point, but it doesn't carry the same weight in a procurement review.

A realistic timeline

Companies starting from close to zero, no formal policies, no access reviews, no centralized logging, are usually looking at three to six months of readiness work before the audit period even starts. Add the Type II observation window (three months minimum, often six to twelve) on top of that, and you're realistically eight months to a year from a cold start to a finished report.

Companies that already have decent security hygiene, MFA everywhere, a real offboarding process, some logging in place, can compress the readiness phase significantly. The honest answer to "how long will this take us" always depends on where you're starting from, which is exactly why a scoped readiness assessment up front matters more than a generic timeline.

Common misconceptions

"We'll buy a compliance tool and it'll basically do this for us." Automation platforms are genuinely useful for evidence collection and continuous monitoring, but they don't write your policies, fix your access control gaps, or manage your vendor risk process for you. They're a piece of the toolkit, not a substitute for the work.

"SOC 2 means we're secure." A SOC 2 report means your controls, as scoped, met the standard during the audit period. It's a strong signal to buyers, but it's not a guarantee against every possible incident, and it's not the same thing as a penetration test or a full security program.

"We can get certified in a few weeks." Vendors sometimes imply this. It's not accurate for a Type II report, which by definition requires an observation period of months. Anyone promising a fast Type II report is describing something other than what enterprise buyers are actually asking for.

"Once we have the report, we're done." The report has to be renewed, generally annually, and the controls behind it have to keep operating in between. It's a program, not a project.

Where traztech fits in

traztech runs fixed-scope SOC 2 readiness engagements: we assess where your controls stand today, build the policies and processes you're missing, and get you audit-ready on a defined timeline. We then coordinate with an independent CPA auditor to run the actual attestation, since by design that has to be a separate firm from the one that helped you prepare. Our compliance readiness services cover SOC 2 as well as adjacent frameworks buyers ask for in the same procurement cycle.

If your team is fielding security questionnaires without a program to back them up, our fintech security and compliance work covers a lot of the same ground for companies handling regulated financial data, where SOC 2 is usually just the starting point.

Getting started

The best first step is usually a short readiness assessment: an honest look at your current controls against the SOC 2 Security criterion, with a realistic timeline and cost attached before you commit to anything. If you're fielding a customer request for a SOC 2 report, or you know one is coming, get in touch and we'll help you figure out where you actually stand and what it will take to get there.

Scope is the decision that shapes everything else

Before any control work starts, someone has to decide what the report covers. That decision drives cost, timeline, and how useful the finished report is to the customer who asked for it. Scope means the specific system: which product, which environments, which infrastructure, which supporting processes, and which parts of the company are in and out. A company with one product and one production account has an easy answer. A company with a flagship platform, an acquired product on separate infrastructure, and an internal tool that touches the same database has a real decision to make, and getting it wrong in either direction is expensive.

Scoping too narrowly produces a report your buyer rejects because the system described is not the system they are buying. Scoping too broadly means you are operating controls, and paying an auditor to test them, across systems nobody asked about. The practical test is to read the description as your customer's vendor risk analyst would: does the boundary in the report match the thing they are about to put their data into.

Two related pieces catch first-timers off guard. Your own critical vendors, the cloud provider and any subservice organization that performs part of the service on your behalf, are handled either by carving them out and relying on their reports or by including them in yours. Nearly everyone carves out, which means you must collect and review those vendors' own SOC 2 reports annually, and your auditor will ask to see that you did. The other piece is complementary user entity controls, the things your report says your customers must do for the controls to work. Those are not filler. Enterprise buyers read them and occasionally push back, so write them to describe reality rather than to shift responsibility.

What auditors actually ask for

Testing is mostly sampling. For a Type II report, the auditor takes a population and pulls a sample from it, then asks you to evidence that the control operated for each item drawn. Access reviews are a good example: they will ask for the list of reviews performed during the period, select two or three, and ask for the review artifact, the date it happened, who performed it, what was found, and proof that anything flagged was actually removed. If your review consists of a screenshot with no reviewer name and no follow-up trail, it fails, even though the review technically happened.

Expect similar treatment across the common control areas. Onboarding and offboarding samples pulled against your HR records, where the auditor compares termination dates against access revocation timestamps and asks about anything with a gap. Change management samples pulled from your repository, checking for review and approval before merge, which is why enforcing branch protection matters more than writing a change management policy. Backup and restore evidence, where a documented restore test beats a description of your backup schedule. Incident tickets, including the ones that turned out to be nothing, because a period with zero incidents recorded reads as a monitoring failure rather than a quiet year. Vendor reviews, security awareness training completion, and risk assessment records round it out.

The pattern worth internalizing is that auditors test populations, not intentions. Anything you cannot produce a dated, attributable record for will be written up regardless of how well the control works in practice, so decide early where each record lives and who generates it. Teams that keep evidence scattered across chat threads and personal drives spend the audit period reconstructing rather than operating, which is the main reason we give clients a place to keep it, the free traztech Workspace, from the start of readiness rather than the week before fieldwork.

Exceptions, qualified opinions, and what failure actually looks like

SOC 2 is not pass or fail in the way people imagine. If the auditor finds that a control did not operate as described, that becomes an exception noted in the report, usually with your management response beside it. A report with one or two exceptions and a credible remediation statement is common and generally survives procurement review. What buyers react to is a pattern: several exceptions in access management, or an exception that goes to the heart of the service being provided.

A qualified opinion, where the auditor concludes the controls were not suitably designed or did not operate effectively overall, is a different matter and is rare, largely because auditors flag serious problems during the period rather than surprising you at the end. If you are heading that way, the honest move is usually to shorten or restart the observation window rather than to publish a report you then have to explain in every sales call for the next twelve months.

One more mechanism worth knowing: the bridge letter, sometimes called a gap letter. Your report covers a defined period, and customers will ask about the months between the end of that period and today. A bridge letter is a short signed statement from management asserting that nothing material changed. Customers ask for these constantly, so have a template ready.

Choosing the auditor, and what it costs

Budget for three separate things, because they are three separate purchases. There is the readiness work, which is where the gaps get closed and where most of the effort sits. There is the audit fee, paid to an independent CPA firm. And there is tooling, if you choose to buy a compliance automation platform, which is optional and easy to over-buy in the first year. Our own readiness track, SOC 2 in 75 Days, starts from a $3,000 gap analysis, and the published scopes on our pricing page exist so you can compare the readiness half honestly against anyone else before you commit.

Audit fees vary more than most founders expect for what is nominally the same work, and the variance is driven by your readiness position rather than by your size. An auditor pricing an engagement is estimating how much of their time will go into chasing you for evidence, resolving ambiguity about scope, and re-testing controls that fall over on first inspection. When you can show a documented control set, a defined system boundary, and an evidence process that already runs, that estimate drops. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, and the mechanics of how that vetting conversation ran are written up in our auditor vetting case study.

When you interview auditors, ask how many clients of your size and type they handle, who the actual fieldwork team is, what their evidence request process looks like, and how long report delivery takes after fieldwork ends. That last one matters more than it sounds, because a report that lands six weeks late lands after the deal it was meant to unblock.

When SOC 2 is the wrong thing to buy

Several situations call for something else, and it is worth checking before you commit eight months and a meaningful budget. If your buyers are mainly European or your target sector runs on international standards, ISO 27001 may be the certificate they actually recognize, and running a management system against the 93 Annex A controls plus clauses 4 to 10 serves you better than an attestation nobody in that market asks for. Some companies eventually need both, but doing them in the wrong order wastes a year, and our ISO 27001 work exists for teams where that is the genuine driver.

If exactly one customer is asking and you have not tested whether they would accept an alternative, ask them. A meaningful number of enterprise buyers will accept a completed security questionnaire, a recent penetration test report, and a written remediation plan as an interim position with a commitment to a report by a stated date. That conversation costs nothing and occasionally buys you two quarters.

If you are pre-product, pre-revenue, or still changing your architecture every few weeks, the controls you document now will not describe the system you have in nine months, and you will pay to write them twice. If you are a services business with no software product and no customer data at scale, the framework may simply not fit what your clients are worried about. And if your honest position is that your security is weak and you know it, spending the first tranche of budget on fixing access control, logging, and vendor management is better value than spending it on documenting the current state for an auditor. The report follows the program. It does not substitute for one.

Keeping it alive between reports

The year after your first report is where programs quietly decay, because the deadline pressure is gone and the controls that were operated manually stop being operated. The teams that renew smoothly do a small number of things on a schedule and treat them as non-negotiable: access reviews on a fixed date each quarter with the results filed, vendor reviews as vendors renew rather than in one annual panic, a risk assessment refreshed once a year with actual changes in it, an incident log that gets entries, and one tabletop exercise that produces notes. None of this is difficult. It is just easy to skip when nobody outside the company is asking, and the cost of skipping arrives as a stack of exceptions in your next report.