SOC 2 for First-Timers: What to Read, What to Skip, and What to Tell Your CEO

You just got the email. A prospect's security team wants your SOC 2 report. You don't have one. You Google "SOC 2" and land on a 200-page AICPA document, three vendor comparison pages, and a Reddit thread that mostly consists of people saying "just use Vanta." None of this tells you what to actually do on Monday morning.

If it feels like this is happening earlier than it used to, you're right. SOC 2 used to be something you worried about once you were clearly selling upmarket — Series B, dedicated security hire, enterprise sales team. Now even seed-stage startups are getting 100-question security reviews before a POC begins. Buyers aren't just asking "do you have SOC 2?" anymore; they want to understand how you manage risk, how you handle vendors, what your AI data practices look like. The bar moved, and it moved fast. If you're a 5-person team getting this question for the first time, you're not behind — you're exactly where most of the market is right now.

This article is the orientation session nobody gives you. We'll cover what SOC 2 actually is, which official documentation is worth reading (and which isn't), and how to brief management so everyone understands what they're committing to.

What Is SOC 2, Exactly?

SOC 2 (System and Organization Controls 2) is an audit framework created by the AICPA — the American Institute of Certified Public Accountants. An independent CPA firm examines your company's security controls and issues a report that you share with customers.

That's it. It's not a certification you hang on the wall. It's a report from an auditor that says "we looked at their security controls, and here's what we found."

Two flavors exist: Type I (a point-in-time snapshot of control design) and Type II (proof that controls worked over 3-12 months). Most startups start with Type I. For a deeper comparison including cost differences, see our bootstrapped founder's guide to SOC 2.

What Official Documentation Should I Actually Read?

There are really only three documents that matter. Everything else is commentary.

1. AICPA Trust Services Criteria (TSC) — Read This

This is the actual standard. It defines the five Trust Services Categories:

Category	What It Covers	Do You Need It?
Security (Common Criteria)	Access controls, system monitoring, risk management	Yes — required for every SOC 2
Availability	Uptime, disaster recovery, capacity planning	Optional — add if you make SLA commitments
Processing Integrity	Data processing accuracy and completeness	Optional — relevant for financial/data processing
Confidentiality	Protection of confidential information	Optional — add if you handle NDA-level data
Privacy	Personal information handling per privacy commitments	Optional — usually not needed if you're B2B

The TSC document is free on the AICPA website. It's about 200 pages, but the relevant part for most startups is the Common Criteria (CC) series — roughly 30 pages of actual control descriptions. The rest is commentary and examples.

What to read: CC1 through CC9 (the Common Criteria). These are the controls your auditor will evaluate.

What to skip: The detailed examples and implementation guidance unless you're stuck on a specific control. You can always come back to them.

2. SOC 2 Reporting Guide — Skim This

The AICPA publishes a guide for practitioners that explains how the audit process works. It's written for auditors, not for the companies being audited, but it's useful for understanding what your auditor is going to do.

You don't need to read this cover to cover. Skim the sections on management's responsibilities and the description criteria — that's the part that tells you what you need to prepare.

3. The Description Criteria (DC Section 200) — Reference When Writing

When you write your system description — the narrative that explains your company, your systems, and your controls — the AICPA has specific criteria for what it must include. This is worth referencing when you're actually drafting the description, not before.

What You Can Skip Entirely

SSAE 18 (AT-C Section 205) — this is the auditing standard your CPA firm follows. It's their problem, not yours.
SOC 1 documentation — different framework, focused on financial reporting controls. Not what your prospect is asking for.
SOC 3 — a public-facing summary of SOC 2. You can't get a SOC 3 without doing SOC 2 first, so ignore it for now.
The AICPA SOC 2 ebook — it looks helpful, but it's aimed at practitioners (auditors and consultants), not at the company being audited. You won't find a management-friendly explanation in there. Use the CEO briefing template later in this article instead.
Vendor marketing content disguised as education — if the URL ends with a demo request form, treat the content accordingly.

Before You Talk to Auditors: The Mini Readiness Check

Before you start calling CPA firms, do a quick internal assessment. Pick 10-15 key controls from the Common Criteria and for each one write down: (1) what you actually do today, (2) what proof exists, (3) who owns it, and (4) what's missing. This exercise takes a few hours and will save you weeks later because it surfaces the real gaps before you're on the clock with an auditor.

Here's the pattern that catches most teams: they're already doing roughly 80% of the right things from a security standpoint. MFA is on, code reviews happen, access gets revoked when people leave. The problem is documentation. Most companies are only about 20% documented. The gap between "what we do" and "what we can prove we do" is where you'll spend the bulk of your prep time. That's not a controls problem — it's an evidence trail problem.

Don't over-scope early. Start with Security (the Common Criteria) and only add Confidentiality or Availability later if your customers specifically ask for it. Type I evaluates control design, so focus on making your processes consistent and documented before worrying about perfection.

If you want to shortcut this exercise, Screenata can run this readiness check for you. It reads your codebase and cloud environment, maps what you already have to SOC 2 controls, and shows you exactly where the documentation gaps are — so you know what to fix before your auditor ever shows up.

What Your Auditor Will Actually Request

This is the part that surprises most first-timers. You read the Trust Services Criteria and think in abstractions. Your auditor shows up with a control matrix — a spreadsheet with 60-80 line items, each asking for specific evidence. Here's what that actually looks like, based on a real auditor's knowledgebase.

Policy documents you'll need

Your auditor expects written policies. Not aspirational docs — policies that describe what you actually do. The core ones:

Policy	What It Covers	CC Mapping
Information Security Policy	Roles, responsibilities, acceptable use, whistleblower procedures	CC1, CC2, CC5
Access Control Policy	Adding, modifying, and removing user access	CC6
Risk Management Policy	How you identify, rate, and mitigate risks	CC3
Incident Response Plan	Logging, tracking, resolving, and communicating security incidents	CC7
Secure Development Policy (SDLC)	Development, testing, change management, emergency changes	CC8
Data Management Policy	Data classification, retention, disposal, customer data purging	CC6, CC5
Operations Security Policy	Vulnerability management, system monitoring, configuration management, patching	CC7
Business Continuity / Disaster Recovery Plan	Communication plans, recovery procedures, annual testing	CC9

A real auditor will tell you: companies have the right to modify templated control descriptions to match their process. It saves both sides time when the controls are tailored to what you actually do, so that the right kind of evidence can be gathered.

Evidence your auditor expects to see

Beyond policies, auditors want proof that controls are actually operating. This falls into a few categories:

System-generated user lists — for every in-scope system (cloud provider, code repository, database, production network, firewall), your auditor wants a complete and accurate list of users with their roles and permissions. These must be system-generated, not manually typed. They want creation or modification dates on the lists so they can confirm the lists are current.

Screenshots of configurations — password policies, MFA enforcement, encryption-at-rest settings, firewall rules, monitoring alert criteria, MDM enrollment status. Links don't qualify as stable evidence. Your auditor wants screenshots.

Process records — change logs from your version control system, access review reports (typically quarterly), background check records for new hires, security training completion records, penetration test results, vulnerability scan reports.

Population lists — a full list of all changes during the audit period, all employees hired, all employees terminated, all assets, all vendors. The auditor selects samples from these.

How sampling works (you don't need evidence for everything)

If your company made 5,000 code changes during the audit period, you don't need to provide screenshots for every single one. Auditors implement sampling — taking a percentage of the total to represent the whole. Your auditor might select 25 changes from the full list and verify those were tested, reviewed, and approved before deployment.

Any control that occurs throughout the audit period or lists a frequency (including annually) can be sampled. Controls that involve a list of assets can also be sampled. For example, if you have a specific configuration manually set on 50 servers, the auditor may sample 10 to confirm consistency.

Your responsibility: provide the full population list. The auditor's responsibility: select the sample. Full population testing is appropriate and recommended when it's actually less work — like when you only had 12 code changes during the period.

What happens if a control fails?

An audit exception is any instance where a control was not designed appropriately or did not operate as intended. For example, if your control states that all employees use a password manager and your auditor finds that 3 out of 50 sampled employees are not using it — that's an exception.

Three common types:

Misstatement — an error or omission in management's description of the system, their controls, or statement that controls operated effectively.
Deviation — a control existed but didn't operate as described. The password manager example above is a deviation.
Non-performance — a control didn't perform at all during the period. This isn't always a failure. If you didn't hire anyone during the audit period, your "background check on new hires" control simply didn't trigger.

Exceptions don't automatically mean a qualified opinion. Many reports include a couple of exceptions and still receive an unqualified (clean) opinion. If you do get an exception, you can explain the situation and how you fixed it in an optional "management response" section of the report.

Controls that aren't applicable

If you identify controls that don't apply to your setup, document why. For example, if your company doesn't use removable media, note that in the control matrix instead of leaving it blank. If a control doesn't accurately depict your process, provide a short explanation with supporting screenshots. Always discuss inapplicable controls with your auditor before the audit starts.

What to Tell Your CEO

Here's the brief. You can send this almost verbatim.

The situation

A customer (or prospect) requires us to have a SOC 2 report. This is standard for B2B SaaS companies selling to enterprises. Without it, we'll face longer sales cycles and may lose deals entirely.

What SOC 2 involves

An independent CPA firm audits our security practices and issues a report we can share with customers. We need to:

Write security policies — 10-17 documents covering access control, incident response, change management, risk assessment, etc.
Implement controls — make sure our policies match what we actually do (MFA, access reviews, encryption, monitoring)
Collect evidence — prove to the auditor that our controls work (screenshots, configurations, logs)
Pass the audit — the CPA firm reviews everything and issues a report

Timeline and cost

Preparation: 4-12 weeks depending on how much is already in place
Audit: 2-4 weeks
Ongoing: Annual audits

For a full cost breakdown including audit fees, prep tooling, and comparisons between DIY, consultant, and AI-agent approaches, see our bootstrapped founder's guide to SOC 2.

Decisions management needs to make

Scope — Security only (recommended for first audit) or additional categories
Budget — Approve the investment (see cost breakdown linked above)
Auditor selection — We need to choose a CPA firm (we'll recommend options)
Timeline — When do we need the report? Work backwards from there.
Preparation approach — DIY, hire a consultant, or use an AI-powered prep tool

How to Choose an Auditor

This is where most first-timers go wrong. They either pick the cheapest option on Google or ask their accountant, who may not specialize in SOC audits.

What to look for:

SOC 2 volume — ask how many SOC 2 audits they complete per year. You want a firm that does this regularly, not one that treats it as a side project. Fifty or more per year is a good baseline.
Startup experience — firms that work with 10-50 person companies understand your constraints. They won't expect you to have a full-time CISO.
Clear timeline — a good firm gives you a specific timeline with milestones, not a vague "it depends."
Readiness assessment — some firms offer a pre-audit readiness review. This is worth doing if it's your first time.
Reasonable pricing — get quotes from 3-5 boutique firms so you have a baseline. If a quote feels dramatically higher or lower than the others, ask why. For typical audit fee ranges by firm tier, see our cost breakdown.

Firms that work well with startups (not exhaustive, just commonly recommended): Johanson Group, Prescient Assurance, Sensiba San Filippo, Schellman, A-LIGN. Ask around in founder communities — referrals from companies your size are the best signal.

Red flags to watch for:

Suspiciously cheap pricing — if a quote is well below the others you received, ask how they're pulling it off. Either the labor is heavily offshored or corners are being cut.
Big 4 firms (Deloitte, PwC, EY, KPMG) — unless you specifically need the brand name for investor or customer reasons. They cost significantly more and the process is slower.
Cookie-cutter approaches — SOC 2 is more "art" than "science" when it comes to control definitions. A good auditor tailors controls to your specific risks and service commitments. If they hand you a completely standardized template with no questions about your actual environment, that's a warning sign.
Unrealistic timelines — any firm promising you'll be "SOC 2 ready in a month" is overselling. For a first-time Type I, expect 90-120 days of prep work on your end before the audit itself.
Minimal involvement — firms that will do everything within your automation platform without meaningful engagement are effectively rubber-stamping, not auditing.
Consulting bundled with audit — your auditor should be independent from whoever helps you prepare. If the same firm wants to sell you readiness consulting and then audit the result, that's a conflict.

One thing that's easy to overlook: make sure your customers will actually accept reports from the firm you choose. A SOC 2 report that cost you $20K in audit fees but gets questioned by your biggest prospect is a waste. Ask your customers or prospects whether they have preferences or requirements around the auditing firm.

What management needs to know before picking a firm

When you present auditor options to ownership, they'll want to make an informed decision without having to learn the entire SOC 2 framework. Here's what to prepare for that conversation:

Why this costs what it costs. Audit pricing is driven by scope (how many systems, cloud environments, and Trust Services Categories are included), your readiness (companies with well-documented policies and established controls cost less to audit), and the length of the engagement. First-time audits cost more because the auditor has to assess everything from scratch.
What differentiates the firms you're recommending. Don't just present prices. Explain whether the firm tailors controls to your company or uses a generic template, whether they offer a readiness assessment as part of the engagement, and how much support they provide on the system description narrative (the written portion of the report that describes your company and its controls). Some firms leave that entirely to you, which is a bigger lift than most teams expect.
The customer acceptance question. The most important factor isn't audit cost — it's whether your customers will accept the report. Verify with your top prospects or existing customers that they'll recognize the firm before you sign.
This is not a one-time cost. SOC 2 is annual. After Type I, customers will expect Type II within 12 months and a fresh report every year after that. Budget accordingly.
Management time commitment. SOC 2 will require time from engineering, IT, HR, and leadership. If the company isn't willing to commit those resources, the project will stall regardless of which firm you pick.

The 9 Common Criteria — What Your Auditor Is Actually Checking

Here's what each CC category covers with real examples of what auditors request. This is based on actual control matrices used in SOC 2 engagements.

CC1 — Control Environment. Board or management oversight, org structure, hiring practices. Your auditor wants a board charter (or management equivalent), an org chart, evidence of background checks on new hires, employee acknowledgment of a code of conduct, and annual performance evaluations. If you don't have a formal board, management can fulfill these requirements instead — just update the control descriptions to reflect that.

CC2 — Communication and Information. How you communicate security policies internally and externally. This covers your information security policies, whistleblower procedures, product descriptions available to customers, external support channels, MSAs or Terms of Service with security commitments, and evidence that system changes are communicated to affected users.

CC3 — Risk Assessment. How you identify and manage risks. Your auditor expects a documented risk management program, a completed annual risk assessment (including consideration of fraud risk), and a vendor management program with a critical vendor inventory showing risk levels assigned to each vendor.

CC4 — Monitoring Activities. Ongoing evaluation of controls. This means quarterly vulnerability scans on external-facing systems with tracking of critical/high findings to remediation, annual penetration testing with tickets filed for findings, and evidence that remediation meets your defined SLAs.

CC5 — Control Activities. Policies and procedures. Your SDLC methodology, access control policy, data retention and disposal procedures, and backup and recovery requirements. This overlaps with the policy table above.

CC6 — Logical and Physical Access Controls. This is the biggest category, typically 20+ individual controls. User lists for every in-scope system (production network, databases, firewalls, cloud platforms, code repositories). Password configurations matching your policy. MFA enforcement on production systems. Encryption at rest for customer data stores. Quarterly access reviews. Network segmentation. Firewall rulesets reviewed annually. MDM enrollment on employee devices. Physical access controls for data centers. Termination checklists proving revoked access.

CC7 — System Operations. Infrastructure monitoring with configured alert thresholds, centralized log management, incident response plan testing at least annually (with documented attendees, test details, lessons learned, and actions taken), and configuration management baselines.

CC8 — Change Management. A complete list of all changes deployed during the audit period. Evidence that at least one approval is required before merging to production. Your SDLC covering development, testing, review, and approval before deployment — including emergency changes.

CC9 — Risk Mitigation. Business continuity and disaster recovery plan with annual testing (tabletop exercises count), cybersecurity insurance documentation, and written vendor agreements with confidentiality and privacy commitments.

CC6 (access controls) and CC8 (change management) are where most first-timers have the most work to do. If you're already using MFA, doing code reviews via pull requests, and have branch protection enabled in GitHub, you're further along than you think.

How your auditor communicates during a Type 2 audit

One thing that catches people off guard: during a Type 2 observation window, your auditor will typically initiate monthly check-in calls. They'll review evidence with you, help ensure you're on track, and flag potential exceptions before the final report. This isn't adversarial. A good auditor wants you to pass. Use those calls to ask questions about controls you're unsure about.

What About Compliance Automation Tools?

You'll encounter platforms like Vanta, Drata, and Secureframe early in your research. They can genuinely help — they provide policy templates, track controls, automate evidence collection from cloud providers, and manage auditor requests. For small teams without compliance experience, they can save weeks of manual work.

But set your expectations correctly. The templates they provide aren't quite audit-ready out of the box. There's still a decent amount of manual work: tailoring policies to your actual processes, collecting evidence that can't be pulled from APIs (like screenshots of application-level configurations), and ensuring what's documented matches what's actually happening. The platforms are worth it, but they won't do 80-90% of the work for you despite what the sales pitch suggests.

This extends to the newer wave of AI-powered compliance tools. Some promise to "generate your SOC 2 evidence automatically" or claim you can be "audit-ready in days." Evaluate those claims against a simple test: can the tool prove to your auditor that a specific control operated effectively over time, with timestamps, system-generated evidence, and context that matches your actual environment? If the answer involves generic screenshots or templated outputs that don't reflect your real systems, your auditor will flag it. The more specific a vendor's claims about what they automate, the more useful they tend to be. The vaguer the promise, the more work you'll still own.

One practical approach: contact a few tooling vendors and ask them for references to auditors who are experienced with their platform. Talk to several auditors and ask them specific questions about your situation — for instance, how they'd handle the fact that you don't have a board of directors, or that you're transitioning from on-prem to hosted. Pick the auditor whose approach aligns with where your company is, then sign up with whatever tooling they prefer.

Plan for Type II From Day One

Type I is a point-in-time snapshot — it proves your controls were designed correctly on a specific date. It's the right starting point, but your customers will eventually want Type II, which proves your controls actually worked over a period of time.

Plan for this from the beginning. Once you pass Type I, your customers will typically expect a new SOC 2 report every 12 months. Set the observation window for your first Type II based on your maturity: 3 months if you're new to this, up to 12 months if you're more established. Some companies skip Type I entirely and go straight to Type II with a shorter observation window after doing a thorough gap analysis first. That can save money if you're confident in your controls.

If you're building out a new hosted service, make sure you have a production-like environment in place before engaging an auditor. SOC 2 reports are historical — they can only describe what existed at a point in time. Some auditors will require you to have live customers in the environment, while others will accept a production-ready setup. Ask about this upfront so you don't end up in a chicken-and-egg situation.

The 4 Mistakes That Cost First-Timers the Most Time

After talking to dozens of teams who've been through this, the same four mistakes come up again and again.

1. Committing before you understand what "operating effectively" means in practice. Most teams start their SOC 2 journey by talking to auditors and vendors in the same week. Within a month, they've signed contracts, locked into timelines, and agreed to scope boundaries they don't yet understand at a practical level. The problem isn't that they picked the wrong vendor. It's that they committed before understanding what the audit would actually require of them day to day.

"Operating effectively" is the phrase that trips everyone up. Your auditor evaluates whether controls operated effectively over the observation period. Most first-time teams interpret that as "the tool is turned on" when it actually means "you can prove the tool did what your policy says it does, consistently, with evidence, for every relevant instance during the period." That gap between what you think you're signing up for and what the audit actually demands is where the real cost hides. Engineers are burned out, evidence collection is ad-hoc, and leadership is asking why this is harder than anyone promised.

The fix: do the mini readiness check above before you sign anything. Talk to at least one person who's been through a SOC 2 audit at a company your size. The three months of trial and error that most first-time CTOs go through is avoidable if you get one honest conversation with someone who's seen how these audits actually play out.

2. Over-scoping. You read about the five Trust Services Categories and think you need all of them. You don't. Start with Security only. Adding Availability or Confidentiality doubles the evidence you need to produce and the controls your auditor tests. Add categories later when a specific customer contractually requires them. Every extra category you include on your first audit is weeks of additional work with no immediate payoff.

3. Ignoring the policy-to-evidence gap. Your team is probably already doing most of the right things — MFA is on, code reviews happen, access gets revoked when people leave. The problem is you can't prove it to an auditor. The gap between "what we do" and "what we can demonstrate we do" is where prep time actually goes. Start collecting evidence now. Pull user lists, screenshot configurations, export change logs. Don't wait until the auditor asks.

4. Choosing the wrong auditor. This one is expensive to get wrong. A cheap firm that rubber-stamps your automation platform output may produce a report your biggest prospect won't accept. An overqualified firm will charge far more than you need to spend. The sweet spot is a boutique firm that specializes in SOC audits for companies your size, tailors controls to your actual risks, and whose reports your customers will recognize. Before you sign, ask your prospects if they have preferences around auditing firms. An audit that gets questioned is worse than a slightly cheaper audit that gets accepted without hesitation.

Questions to Ask When Evaluating Firms and Tools

When you start emailing audit firms and tooling vendors, generic questions get polished sales answers. Here's how to get useful information instead.

For audit firms, ask: Are you a licensed CPA firm and what's your latest peer review status? What does your "readiness assessment" actually include as a deliverable? Can you share a redacted report outline? How do you set scope and boundaries? What are the top two reasons you see first-timers slip their timelines? Do you tailor controls to the company or use a generic set? What support do you provide for the system description narrative — is that entirely on us?

For tooling vendors, ask: Can you show me what evidence is truly auto-collected versus still manual for our exact stack? How do you handle exceptions or compensating controls when something doesn't fit a standard template? How long does setup really take and who does the work? Can our auditor get read-only access to review evidence directly in your platform?

One tip that saves everyone time: before you reach out, put together a one-page context sheet with your tech stack, rough scope (Security only or additional categories), target date, and current state (what policies exist, what tools you use for access management, ticketing, and version control). You'll get significantly better answers from both auditors and vendors when they know what they're working with.

What to Do This Week

Read the Common Criteria (CC1-CC9) in the AICPA Trust Services Criteria. Set aside 90 minutes. You don't need to understand every nuance, just the categories.
Do the mini readiness check — pick 10-15 controls and write down what you do today, what proof exists, who owns it, and what's missing. This is the single most useful prep exercise you can do.
Brief your CEO or leadership using the template above. Get budget and timeline alignment early. If management isn't serious about committing the resources — particularly the time required from participants — the project will stall.
Define your scope — which systems, environments, and teams fall under SOC 2. If you're building a new hosted offering, clarify what environment needs to exist before an auditor will engage.
Start collecting user lists — pull system-generated user lists from your cloud provider, code repositories, and production databases. These take time to gather and your auditor will need them for every in-scope system.
Start the auditor search — reach out to 3-5 boutique firms for quotes. Ask about their approach to scoping, how they handle exceptions, and whether they have experience with companies your size. SaaS audit experience matters more than geography — most SOC audits are done remotely now.
Pick a preparation approach — writing policies yourself, hiring a consultant, or using a tool that generates them from your actual systems.

The mistake most teams make is spending weeks researching before doing anything. SOC 2 is not conceptually hard. It's a documentation exercise with specific deliverables. The control matrix above shows you exactly what those deliverables are. The gap is almost always between what you're already doing and what you can prove. Start closing that gap now.

Learn More About SOC 2 for Bootstrapped SaaS

For a complete breakdown of costs, timelines, and preparation paths, see our guide on the bootstrapped founder's guide to SOC 2, including cost comparisons between DIY, consultant, and AI-agent approaches for startups under 50 employees.