Every few weeks I get some version of the same phone call about SOC 2 compliance. A founder or operations lead at a services firm has just watched a promising deal slow to a crawl. The prospect’s procurement team sent over a security questionnaire, and sitting right at the top was one question: “Please provide your most recent SOC 2 report.” They don’t have one. They aren’t entirely sure what one is. And the person on the phone usually has about ninety days and a very nervous sales team.
I’ve spent most of my career in cybersecurity and IT compliance, and for the last several years I’ve worked as a fractional CISO (what people now call a vCISO) for small and midsize service companies. Managed IT providers, payroll and HR outsourcers, bookkeeping firms, staffing agencies, marketing shops that handle customer lists, and a fair number of software companies. SOC 2 compliance comes up in nearly every one of those engagements. Not because anyone woke up excited about an audit, but because their customers started asking.
This guide is the conversation I have with new clients in our first week together, written down. No jargon for the sake of it, no product pitch. Just what SOC 2 is, what it actually asks of you, what it costs, and where companies like yours tend to stumble.
What SOC 2 Compliance Actually Means
SOC 2 is a reporting framework created by the American Institute of Certified Public Accountants, better known as the AICPA. It belongs to a family of reports called System and Organization Controls. According to the AICPA, the purpose of a SOC 2 report is to give your customers, business partners, and other interested parties information about your controls relevant to security, availability, processing integrity, confidentiality, or privacy, so they can evaluate the risk of relying on you.
Hold onto that idea, because it explains almost everything else. SOC 2 exists so your customer can trust you with something they care about, usually their data or their uptime, without sending their own auditors into your office. It came along in 2011 as a successor to the old SAS 70 reports, and it was built with outsourced service providers in mind.
Three Things SOC 2 Is Not
Clearing these up early saves a lot of confusion later.
It is not a certification. You’ll hear “SOC 2 certified” constantly, including from salespeople who should know better. What really happens is that a licensed CPA firm examines your controls and issues an attestation report containing their opinion. There is no certificate to hang on the wall and no governing body that grants you a badge. That difference matters more than you’d think when a buyer’s legal team reads your website.
It is not a checklist. Frameworks like PCI DSS tell you fairly precisely what to do. SOC 2 gives you criteria and expects you to design your own controls that satisfy them. Two companies can both receive clean reports with very different control sets. For small firms, that flexibility is a real advantage. For anyone hoping to fill in a template over a long weekend, it’s a trap.
It is not a law. No regulator fines you for skipping SOC 2 compliance. The penalty is commercial: stalled deals, longer procurement cycles, and losing to a competitor who had the report ready when the questionnaire arrived.
Who Needs SOC 2 Compliance?
If you store, process, or have access to a client’s data or systems, you are a candidate. In my own client work, that has meant managed service providers with administrative access to customer networks, payroll and benefits firms holding employee records, accounting practices with logins to client financial systems, staffing agencies processing candidate information, analytics and marketing agencies handling customer lists, and, of course, software and SaaS companies.
The real trigger, though, is your customer list. Once you start selling to midmarket and enterprise organizations, particularly in financial services, healthcare, or technology, their vendor risk teams will ask. Small clients rarely do.
So my first question to any new client is never “Do you need SOC 2?” It’s “Who is asking, and what exactly did they ask for?” Sometimes a thoughtfully completed questionnaire and a decent policy set will satisfy a buyer for now. Other times the contract literally names a SOC 2 Type 2 report as a condition of renewal. Those are two very different projects with very different budgets, and you want to know which one you’re in before you spend a dollar.
The Five Trust Services Criteria Behind SOC 2 Compliance
Every SOC 2 report is built on what the AICPA calls the Trust Services Criteria. The version in use today is the 2017 criteria with revised points of focus published in 2022, and it’s aligned with the 17 principles of the COSO internal control framework. You don’t need to memorize any of that. Here’s how I explain the five categories to a CEO over coffee.
Security is the only mandatory category. It’s also known as the Common Criteria, numbered CC1 through CC9, and it covers the foundations: governance and oversight, risk assessment, access control, change management, system monitoring, incident response, and vendor management. Every SOC 2 report includes it, no exceptions.
Availability asks whether your service stays up the way you promised. Add it if an outage on your side would stop your clients from doing their own work, or if your contracts include uptime commitments.
Processing Integrity asks whether your system does what it claims to do, completely, accurately, and on time. Payroll processors, billing services, and anyone producing financial outputs should think about this one.
Confidentiality covers information you’ve agreed to keep secret, such as client contracts, intellectual property, pricing, or strategic documents you host.
Privacy deals with personal information about individuals: how you collect it, use it, retain it, and dispose of it.
Choosing Criteria for Your SOC 2 Compliance Scope
Here’s the advice I give almost every first time client: start with Security, add only what your customers actually require, and resist the urge to include everything just to look thorough. Published guidance estimates that adding categories you don’t need can inflate your costs by 30 to 50 percent, and that matches what I’ve seen. I once watched a 25 person agency add Privacy and Processing Integrity because a larger competitor’s report included them. They spent two extra months building controls that no customer ever asked about.
SOC 2 Compliance Reports: Type 1 vs Type 2
A Type 1 report examines your controls at a single point in time and answers one question: are these controls designed properly? A Type 2 report examines a period of time, typically somewhere between three and twelve months, and answers a harder question: did these controls actually operate, consistently, for the whole period?
The analogy I use: a Type 1 is a photograph of your kitchen right after you cleaned it. A Type 2 is a camera mounted in the kitchen for six months.
Most enterprise buyers want a Type 2. But Type 1 still has a legitimate role. If you’ve just finished building your controls and a specific prospect needs something now, a Type 1 can carry you while your Type 2 observation window runs. There’s no required waiting period between the two, so you can begin your Type 2 window right after your Type 1 date and the work carries forward.
Which One Should You Choose?
My rule of thumb is simple. If a deal is waiting and the buyer explicitly accepts a Type 1, do the Type 1 and roll straight into a Type 2. If nothing is forcing your hand, skip the Type 1 and go directly to a Type 2 with a shorter first window. Six months is common for a first audit, and three is possible if your controls are already mature.
One warning, learned the hard way by more than one client. Don’t choose an observation window that starts before your controls are truly running. Industry guidance calls this the most expensive avoidable mistake in a first audit, and I agree completely. If your quarterly access review didn’t happen in month one, the auditor will find that gap, and it will show up in your report as an exception your customers will read.
What SOC 2 Compliance Work Actually Looks Like
People imagine SOC 2 compliance as a single event: the audit. In reality the audit is the last few weeks of a much longer project. Here’s the path I walk clients through.
1. Scope the system honestly
Define what’s in and what’s out: the specific services you’re reporting on and the people, infrastructure, software, data, and procedures behind them. A tight, well defined scope is cheaper to audit and easier to defend. If your company runs three service lines but only one touches client data, scope that one first.
2. Map your vendors
Almost every service company relies on cloud providers, and in SOC 2 language those providers are “subservice organizations.” Most companies use what’s called the carve out method. Your report describes what a provider like AWS or Microsoft does for you, excludes their internal controls from testing, and lists the controls you’re assuming they perform. Those are called complementary subservice organization controls, or CSOCs.
The catch is that carving them out doesn’t make them disappear. You’re expected to obtain and actually review your key vendors’ SOC 2 reports on a regular basis. I’m genuinely amazed how often that “annual vendor review” turns out to be a PDF nobody ever opened.
3. Run a gap assessment
Compare what you do today against the criteria. Most small service firms I work with already do roughly half of what they need. They just haven’t written any of it down. The gaps I see over and over are no formal risk assessment, no written incident response plan, inconsistent offboarding, missing security awareness training records, nobody reviewing logs, and change management that lives entirely in one engineer’s head.
4. Remediate and document
This is where the real work lives: policies, procedures, and technical fixes. Multifactor authentication on everything, centralized identity management, endpoint protection, encrypted backups that you actually test restoring, background checks for new hires, and documented access reviews.
A note on policies, because this is where I see the most self inflicted pain. Write policies you will actually follow. The auditor tests you against your own words. If your policy says you review firewall rules monthly and you do it twice a year, that’s an exception. A 40 page policy borrowed from a bank isn’t an asset. It’s a liability with your logo on it.
5. Operate and collect evidence
During the observation period, your controls must run and leave a trail: tickets, screenshots, system logs, signed policy acknowledgments, minutes from your risk review meetings. Auditors don’t examine every single event. They sample. But the samples have to hold up. Start collecting evidence on the first day of the window, not the week before fieldwork.
6. The examination
Once the window closes, the CPA firm tests your controls and issues the report, which includes their opinion, your system description, the controls, the tests they performed, and any exceptions they found. Fieldwork and reporting usually take a few weeks. End to end, a first Type 2 typically runs six to twelve months from the start of readiness work to report in hand.
What SOC 2 Compliance Really Costs
Costs vary widely with company size, scope, and how much you’ve already built. To give you a sense of current market ranges published this year: Type 1 auditor fees often fall somewhere around $15,000 to $50,000. Type 2 audit fees commonly land between $25,000 and $75,000. Compliance automation platforms run roughly $10,000 to $50,000 per year, and internal engineering time for a first audit can add another $20,000 to $50,000 in loaded cost. One analysis put the average all in cost of a first time Type 2, including staff time, near $147,000.
The Hidden Cost Is Your Team’s Time
My honest take after many of these: for a 20 to 75 person service company with a sensible scope, the audit fee is rarely the scary number. The hidden cost is your people’s time. Someone has to own your SOC 2 compliance program. If that someone is your CTO doing it at 11 p.m. after a full day of client work, you’ll pay for it in burnout and missed evidence. That’s usually where a fractional CISO or a dedicated compliance lead earns their keep.
The good news is that year two is cheaper. Most of the remediation is behind you, so ongoing costs shrink to the platform, the audit fees, and a lighter lift from your team.
A Word on SOC 2 Compliance Automation Tools
Every client asks about these. They’re genuinely useful. They pull evidence from your systems, track tasks, and provide policy templates. But they don’t make you secure. They make you organized. I’ve audited companies with every dashboard showing green and an administrator account shared by four people. Eventually an auditor notices that kind of thing. So do attackers.
The Parts of the Report Most People Skip
When clients receive their first SOC 2 report, or when they’re reading a vendor’s, two sections tend to get skipped. Both matter.
Complementary User Entity Controls
The first is the list of complementary user entity controls, or CUECs. These are the controls your customers are expected to operate on their end for your controls to work. A classic example: if a client’s employee leaves, the client has to tell you so you can remove that person’s access to your portal.
Here’s the part that surprises people. The auditor’s opinion is conditional. It holds only if your customers run their CUECs and your carved out vendors run their CSOCs. So when you’re the buyer, read your vendor’s CUEC section carefully. When you’re the one being audited, make your CUEC list clear and practical.
Exceptions Are Not Failures
The second is the exceptions section. A report can contain exceptions and still carry a clean opinion. What sophisticated buyers want to know is whether the exception was isolated and how management responded. A short, honest management response is far better than vague language that makes a reviewer wonder what you’re hiding.
Keeping SOC 2 Compliance Alive Between Audits
SOC 2 compliance isn’t a one time project. Your report covers a period that’s already in the past, and customers want reasonably recent assurance. Most companies settle into an annual rhythm: observation period, audit, report, repeat.
Bridge Letters
That rhythm creates gaps. If your report period ended in June and a customer asks in October, you’ll likely provide a bridge letter, sometimes called a gap letter. It’s written by your management team, not your auditor, and it states that no material changes have occurred to your controls since the report period ended. Bridge letters ideally cover three months or less, and they’re never a substitute for the report itself.
Build a Compliance Calendar
The most practical thing I do for clients after their first audit is build a compliance calendar with named owners. Quarterly access reviews. An annual risk assessment. Annual security awareness training. Annual vendor report reviews. An incident response tabletop exercise. A yearly policy review. Most of the exceptions I see in a company’s second year come from recurring tasks that quietly slipped once everyone got comfortable.
SOC 2 Compliance Mistakes I See Again and Again
Treating SOC 2 as an IT project. It touches HR (background checks, onboarding, offboarding), finance (vendor contracts), and leadership (risk oversight and governance). If the CEO isn’t involved, the auditor will notice.
Copying another company’s policies wholesale. Your policies describe your company. Borrowed ones describe someone else’s.
Over scoping to look impressive. Every extra category means more controls, more evidence, more testing, and more cost.
Waiting until a deal forces it. The companies that struggle most are the ones starting from zero with a signed contract deadline. Six months of runway changes everything.
Ignoring vendors. Your report is only as strong as the providers you rely on and how well you oversee them.
Calling yourself “SOC 2 certified” in marketing. It’s a small thing, but experienced buyers notice, and it can quietly undermine your credibility.
Where to Start Your SOC 2 Compliance Journey This Week
You don’t need to have everything figured out to make real progress. If SOC 2 compliance is on your horizon, here’s what I’d do in the next five business days.
Find out exactly what your customers are asking for. Type 1 or Type 2? Which criteria? By when? Get it in writing if you can.
Name one owner. Not a committee. One person who is accountable for the program, with the authority and time to run it.
List every system and vendor that touches client data. This becomes the foundation of your scope.
Turn on multifactor authentication everywhere it isn’t already enabled. It’s the single highest value control I know, and auditors will look for it.
Write a one page incident response plan. Who gets called, who decides, who talks to customers. You can expand it later.
Talk to two or three CPA firms early. Ask about their experience with companies your size and in your industry, how they handle readiness, and what their typical timeline looks like. Choosing an auditor isn’t just a price comparison. A good one will make your first audit far smoother.
The Bottom Line
SOC 2 compliance can feel intimidating from the outside, mostly because of the vocabulary. Underneath the acronyms, though, it asks a fair question: can your customers trust you with what they’ve handed over? If you approach it as a way to run your company more deliberately, rather than a box to check for sales, you’ll end up with a stronger business and a report that actually means something to the people reading it.
Frequently Asked Questions About SOC 2 Compliance
Is SOC 2 compliance legally required?
No. SOC 2 isn’t a law or regulation. It’s a voluntary attestation that becomes effectively required when customers write it into contracts or vendor risk policies. The consequence of not having one is lost or delayed business, not government penalties. The AICPA’s overview of the SOC suite explains the purpose of each report type.
How long does it take to get a SOC 2 report?
For a first Type 2, plan on six to twelve months end to end: a few weeks to a couple of months of readiness and remediation, an observation period of three to twelve months, and a few weeks of examination and reporting. A Type 1 is faster because there’s no observation window. Scrut’s SOC 2 compliance timeline guide breaks down a typical timeline.
What’s the difference between SOC 2 Type 1 and Type 2?
Type 1 evaluates whether your controls are properly designed at a single point in time. Type 2 evaluates whether those controls operated effectively over a defined period. Most enterprise buyers prefer Type 2. Scrut’s comparison of Type 1 and Type 2 covers when each makes sense.
Do I have to include all five Trust Services Criteria?
No. Only Security is mandatory. Availability, Processing Integrity, Confidentiality, and Privacy are optional and should be added based on the services you provide and what your customers require. See Secureframe’s breakdown of the Trust Services Criteria for guidance on choosing.
If we host everything on AWS or Azure, are we already covered?
Not entirely. Your cloud provider’s SOC 2 report covers their infrastructure, not how you configure and use it. Most companies use the carve out method, which still requires you to review your providers’ reports and manage your own controls on top of theirs. Compass IT Compliance explains the carve out and inclusive methods in detail. If you’re still deciding where to host, our cloud migration strategy guide covers the planning side.
How long is a SOC 2 report good for?
A report covers a specific past period, and most buyers expect one issued within roughly the last twelve months. Companies typically renew annually and use a bridge letter to cover short gaps between report periods. Scrut’s guide to SOC 2 bridge letters shows what one should include.
Can a small company realistically achieve SOC 2 compliance?
Yes. Small firms often move faster because they have fewer systems and fewer people to coordinate. The keys are a tight scope, policies that reflect how you really operate, and one accountable owner. A-LIGN’s overview of SOC 2 requirements is a good starting point for planning.
What are complementary user entity controls (CUECs)?
CUECs are controls your customers are expected to operate on their side, such as managing their own users’ access to your platform. The auditor’s opinion assumes those controls are in place. ZenGRC’s explanation of CUECs walks through practical examples.
References
- System and Organization Controls: SOC Suite of Services (AICPA & CIMA)
- SOC 2 Reporting on an Examination of Controls at a Service Organization (AICPA & CIMA)
- SOC 2: System and Organization Controls Reporting Whitepaper (KPMG)
- System and Organization Controls (SOC) Reporting (Baker Tilly)
- SOC 2 Trust Services Criteria (Secureframe)
- SOC 2 Trust Services Criteria: A Practical View for Security Teams (Bright Defense)
- SOC 2 Compliance Requirements: An Overview (A-LIGN)
- SOC 2 Type 1 vs Type 2: Key Differences, Costs, and When to Choose Each (Scrut)
- SOC 2 Type 2 in 2026: Requirements, Process, and Cost (Sprinto)
- SOC 2 Type 2: The Complete 2026 Guide (Strac)
- SOC 2 Compliance Timeline: How Long Does It Take to Achieve Compliance? (Scrut)
- SOC 2 Bridge Letter: Key Insights and Guidelines (Scrut)
- SOC 2 Bridge Letter Guide and Template (Sprinto)
- Subservice Organizations in SOC Reports: Carve Out vs Inclusive Method (Compass IT Compliance)
- Complementary User Entity Controls Explained (ZenGRC)
