Your First SOC 2 Audit: What to Do in the First 30 Days

SOC 2 is not a certification. It is an audit report issued by an independent CPA firm, governed by the AICPA's Trust Services Criteria. The report says whether your controls satisfy those criteria — it does not prescribe which controls to use. That flexibility is useful, but it means you need to document the why behind every control, not just prove you have one.

Two types of SOC 2 reports exist:

• Type I evaluates the design of your controls at a single point in time. Think of it as a snapshot — “as of this date, these controls exist and are designed properly.”
• Type II evaluates both design and operating effectiveness over a period of time (the observation window). This is what enterprise buyers actually want, because it proves your controls worked consistently, not just that they existed when the auditor looked.

Most companies start with Type I to prove readiness, then pursue Type II. Some skip straight to Type II if they are confident in their controls and willing to commit to the longer timeline. Your auditor can advise which path fits, but know this: a Type I report does not shorten your path to Type II. The observation period starts when you say it starts, regardless of whether you did a Type I first.

The single highest-leverage decision you will make this week is scope. SOC 2 does not require you to audit your entire company. You can scope to a single product, a single service, or a single system — and you should. A tighter scope means fewer controls to implement and document, fewer teams involved, a faster and cheaper audit, and less surface area for findings. You can always expand scope later.

This is the single most important thing you will do in week one, and it is the thing that bites the hardest when you skip it.

Every access review you conduct, every vendor you assess, every policy you draft, every configuration change you make — timestamp it and save it. Your auditor will ask for evidence that your controls operated consistently throughout the observation period. If you did not log it when it happened, you will be reconstructing it from memory six months from now, and that is where first-time audits go sideways.

Your evidence log does not need to be sophisticated. A shared folder with a consistent naming convention works. A spreadsheet with dates, control references, and links to artifacts works. What does not work is “we will organize this later.”

SOC 2 has five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Of these, Security is the only one required for every SOC 2 audit. The others are optional and additive — you include them based on what your product does and what your customers expect.

The Security category covers nine Common Criteria (CC1 through CC9):

• CC1 — Control environment (governance, org structure, accountability)
• CC2 — Communication and information (internal and external)
• CC3 — Risk assessment (identifying and analyzing risks)
• CC4 — Monitoring activities (ongoing evaluation of controls)
• CC5 — Control activities (policies and procedures)
• CC6 — Logical and physical access controls
• CC7 — System operations (detecting and responding to anomalies)
• CC8 — Change management
• CC9 — Risk mitigation (vendor and business partner oversight)

Do not try to tackle all nine in one sprint. Start with CC6 (access controls) and CC8 (change management) — these are where most startups have the biggest gaps. If you use a cloud provider, you likely inherit some controls from them; your auditor can help you map what is inherited versus what you own.

At minimum, you will need these policies drafted by the end of week two:

• Information Security Policy
• Access Control Policy
• Change Management Policy
• Incident Response Plan
• Risk Assessment Policy
• Vendor Management Policy — CC9.2 requires you to assess and manage vendor and business-partner risk; this is how you evidence it

These do not need to be long. A five-page policy that reflects how your team actually works is worth more than a thirty-page template that nobody follows. Auditors test whether you follow your own policies — so write policies you can actually follow.

Vendor management is probably the single biggest hidden time sink in your SOC 2 preparation. You need to identify every third party that touches customer data — cloud providers, analytics tools, payment processors, email services, monitoring platforms — and document whether they have their own SOC 2 or equivalent assurance. This is not a one-afternoon task. Start building your vendor inventory now. For a deeper look at how to approach this without drowning in spreadsheets, see Vendor risk assessments for startups — a tiered approach auditors accept.

Auditors will want to see that you review who has access to what — and that you do it on a regular schedule. Pick a cadence and write it down — quarterly is a common choice. What gets tested is not the number, it is whether you hit the number you committed to. That means:

1. Pull a list of everyone with access to your production systems, source code repositories, and customer data stores.
2. Verify each person still needs that access for their current role.
3. Remove access that is no longer justified.
4. Log the review with a date and reviewer name.

The first review will take longer than you expect. That is normal. The important thing is that it happens inside your observation window so the auditor can see the pattern.

If you have not engaged an auditor by day 15, start the conversation now. Auditor selection matters more than most first-timers realize:

• Look for SOC 2 experience with companies your size. A firm that audits Fortune 500 companies will apply a level of rigor (and cost) that does not match a 20-person startup.
• Ask about a readiness assessment. Most firms offer a pre-audit gap analysis that identifies issues before the observation period starts. Worth the cost.
• Understand the timeline. Scheduling can add months. Book early.
• Get pricing in writing before you commit. Scope drives cost more than company size does, so narrow your scope first and quote second.

Your auditor is going to ask how you know your controls are working between reviews. By day 30, you should have centralized logging for authentication events and system changes, alerting on failed logins and privilege escalations, uptime monitoring for customer-facing services, and a process for reviewing alerts.