It usually starts with five questions
If your company is going through SOC 2 for the first time, there’s a good chance the process landed on the CTO, Head of Engineering, or whoever happened to say, “Sure, I can figure this out.”
Then the questions begin.
- What exactly do we need?
- Is this evidence good enough?
- Are these policies actually necessary?
- What will the auditor look at?
- Are we ready to start the audit?
And perhaps the most frustrating one: Why can’t anyone tell us whether we’re actually ready before the audit begins?
SOC 2 shouldn’t be a black box
For many first-time companies, the process looks something like this:
You choose your Trust Services Criteria. You write policies. You connect a compliance platform. You collect screenshots, tickets, access reviews, vendor assessments, logs, and dozens of other pieces of evidence.
Eventually, you hand everything to an auditor.
And only then do you discover what isn’t good enough.
That’s backwards. The audit itself should confirm that your controls operated as expected. It shouldn’t be the first time you learn that the evidence you spent months collecting doesn’t demonstrate what you thought it did.
Evidence is not the same as audit-ready evidence
This is one of the biggest lessons for companies doing SOC 2 for the first time.
Having a document doesn’t necessarily mean you have evidence. Having a policy doesn’t mean the control operated. Having a screenshot doesn’t necessarily prove what the auditor needs to test.
For every control, you should be able to answer three simple questions:
What does this control require us to do? What evidence proves we actually did it? Would an independent auditor be able to reach the same conclusion from that evidence?
If the third answer isn’t clear, you’re probably not audit-ready yet.
Example: evidence for an access review control
Your control says: User access to production systems is reviewed quarterly.
Not audit-ready
A Slack message that says “I reviewed access and it looks fine.”
Audit-ready
- A screenshot or PDF export from your identity provider
- Clearly shows the date of the review
- Lists every user and their role/permissions
- Shows who performed the review
- Notes any removals or approvals with timestamps
The second example lets an independent auditor see that the review happened, who did it, what was covered, and what the result was. The first example asks the auditor to trust a note.
The minimum evidence list, from a real case
Let’s make this concrete. A 12-person SaaS — React frontend on Vercel, a Node API on AWS, PostgreSQL on RDS, GitHub, Linear, Google Workspace, Sentry — went through its first SOC 2 Type II with a 6-month observation window. No GRC platform, no compliance hire.
This is the complete floor of evidence they handed the auditor. If your stack looks similar, this list is your starting point.
The minimum evidence list — from a real first audit
This is the evidence that carried a 12-person SaaS through its first SOC 2 Type II. No GRC platform, no compliance hire — just GitHub, AWS, Google Workspace, Linear, and Sentry. If a control below applies to you, the evidence listed is the floor, not the ceiling.
Access control
- Google Workspace user export showing MFA enforced for every account
- AWS IAM role and policy export — no shared accounts, least-privilege roles
- Quarterly access review: a dated CSV or PDF listing every user, their role, the reviewer, and what was removed or confirmed
Change management
- GitHub pull requests showing code review and approval before merge
- Branch protection settings screenshot — main cannot be pushed to directly
- Linear or Jira tickets linked to PRs for the changes sampled in your audit window
Authentication & customer data
- Auth provider settings export (Supabase Auth, Auth0, or Clerk) showing password policy and session rules
- RDS encryption-at-rest and TLS-in-transit configuration screenshots
- S3 bucket policy export showing no public access to customer files
Monitoring & incidents
- Sentry or Datadog alert configuration showing who gets paged
- Two or three real incident tickets: what happened, when it was detected, how it was resolved
- A one-page incident response plan your team has actually read
Backups & recovery
- RDS automated backup settings showing retention period
- One documented restore test with a date, who ran it, and the result
Vendor management
- A short list of your critical vendors (AWS, Vercel, auth provider, payment processor)
- Their SOC 2 reports or security pages on file, with the date you reviewed them
People & policies
- Signed acceptable use and confidentiality acknowledgment from every team member
- Offboarding checklist evidence for the last person who left: tickets showing access was revoked within 24 hours
- Five to eight core policies — access control, change management, incident response, backups, vendor management — not thirty
Every item above answers the same three questions: what the control requires, proof it happened, and a date an independent auditor can place inside your observation window.
Don’t build a perfect compliance program before your first audit
Another common mistake is trying to implement everything at once.
You don’t need the security organization of a public company to complete your first SOC 2. You need a clearly defined system, appropriate controls for your business and risk profile, people who understand their responsibilities, and evidence showing that those controls actually operated during the audit period.
Start with what matters.
Know your scope. Know your controls. Know who owns them. Know where the evidence comes from. Then fix the gaps that could actually affect your audit.
Your auditor shouldn’t be a surprise at the end
The best first SOC 2 experience shouldn’t feel like submitting an exam and waiting to discover whether you passed.
Before entering the audit, you should already have a pretty good idea of what an auditor is going to see.
That’s why I believe pre-audit should become a normal part of the SOC 2 journey.
Take the evidence you’ve already collected. Map it to the controls. Test whether it actually supports those controls. Identify what’s missing. Prioritize the gaps. Fix them.
Then start the audit.
Professional judgment still belongs with the qualified CPA performing the examination. But companies shouldn’t have to wait until that point to get meaningful feedback on their readiness.
If you’re starting SOC 2 tomorrow, start here
Don’t begin by writing 30 policies.
Begin by understanding:
- What are we auditing?
- What controls apply?
- Who owns each one?
- What evidence should exist?
- Where does that evidence live?
Build that map first.
Everything else becomes much easier once you can see the audit as a system rather than a giant folder of documents.
A simple map for your first SOC 2
SOC 2 is easier to navigate when you can see the whole journey before you start.
Scope & criteria
Pick your system boundaries and Trust Services Criteria. Security is required; Availability, Confidentiality, Privacy, and Processing Integrity depend on what you promise customers.
Control map
List the controls that map to each criterion, assign an owner, and note where the supporting evidence lives.
Evidence collection
Gather screenshots, logs, access reviews, policies, tickets, and vendor docs. Make sure each item answers what the control requires.
Pre-audit review
Test whether your evidence actually supports your controls. Close the real gaps before the auditor arrives.
Audit period
Run your controls consistently for 3–12 months. Evidence must cover the full observation window.
Auditor examination
An independent CPA tests your controls and evidence. No surprises if you did the pre-audit work.
Report & maintain
Receive your SOC 2 Type II report, then keep the program running. Continuous monitoring beats last-minute scrambling.
What this looks like for a minimal SaaS app
Here is a concrete, no-frills stack most early-stage SaaS companies already have. Your actual tools may differ, but the controls stay the same.
System in scope
- React or Next.js frontend hosted on Vercel
- Node/Python API running on AWS (ECS, Lambda, or EC2)
- PostgreSQL database on RDS or a managed service
- Auth provider such as Supabase Auth, Auth0, or Clerk
- Cloud storage (S3 / Cloudflare R2) for customer files
Operations & evidence
- GitHub for source code, pull requests, and reviews
- Linear or Jira for change management tickets
- Datadog / PagerDuty / Sentry for monitoring and incidents
- Google Workspace with SSO and device management
- 1Password or similar for shared secrets and access reviews
Mapped to the seven steps
- Scope: the production AWS region, Vercel app, database, and API.
- Controls: access control, change management, backup, incident response, monitoring, and vendor reviews.
- Evidence: GitHub PRs, AWS CloudTrail logs, access-review CSVs, ticket screenshots, and policy acknowledgments.
- Pre-audit: test that each piece of evidence actually proves the control happened when it should have.
- Observation: run the controls for your chosen window — 3, 6, or 12 months — without gaps.
- Examination: an independent CPA samples the evidence and tests the controls.
- Report: Type II report issued, then keep monitoring and reviewing going forward.
SOC 2 doesn’t have to consume your company
And perhaps that’s the biggest thing I wish more first-time companies knew:
SOC 2 doesn’t have to consume your company.
The goal isn’t to become good at passing an audit. The goal is to build reasonable security practices, prove that they work, and get back to building your business.
That’s what a good audit process should help you do.
Starting SOC 2 for the first time?
Talk to an auditor before you commit to a platform or an audit window. We’ll map your scope, controls, and evidence sources — and show you what ready actually looks like.