SOC 2 when nobody on your team is a security person

A customer just asked for your SOC 2 report. You are the person responsible for getting it. Nobody on your team is a security person. Now what?

If that scenario sounds familiar, you are in good company. Most of the founders and business owners I hear from landed in the compliance seat not because they have a security background, but because they own the enterprise sales process, or the CEO handed it to them, or simply because they are the most organized person in the room. None of those reasons involve expertise in information security. That is fine. SOC 2 is achievable without it.

This post is for you. We will walk through what SOC 2 actually is in plain terms, why your enterprise customers ask for it, what the role of "compliance owner" looks like when you do not have a dedicated CISO, and how to get started this week.

What SOC 2 Actually Is

SOC 2 is a report prepared by an independent auditor (a CPA firm) that confirms your organization handles customer data according to a defined set of standards. Those standards are called the Trust Services Criteria (TSC) — a framework published by the American Institute of CPAs that covers areas like security controls, availability of your service, and how you protect confidential information. The audit looks at whether you actually follow the practices you say you follow, not just whether you have a policy document that says you will.

That is the whole thing. An auditor reviews your controls. You demonstrate that the controls work. They issue a report. You share that report with customers who asked for it.

No regulatory body requires you to have SOC 2. No law mandates it for most industries. Enterprises ask for it because it is the most widely recognized third-party confirmation that a vendor takes data security seriously — and their procurement and legal teams need that confirmation before they will sign a contract with you.

Why Enterprises Ask for It

The short answer: it is a deal-gate. When a company is evaluating whether to buy your product and will be sending you customer data, employee data, or financial data as part of that relationship, their procurement team needs to know you have controls in place. SOC 2 is the documentation that answers that question.

Without it, a vendor assessment can stall for months. With it, you hand procurement a standardized attestation letter — the formal report the auditor issues — and the process moves forward.

This is not security theater. Enterprises have been stung by data breaches at vendors. They have regulatory obligations of their own. When they ask for your SOC 2, they are managing their own risk exposure, not running an academic exercise. Your job is to give them the documentation that lets them say yes.

If you are in early conversations with enterprise buyers and you do not have SOC 2 yet, the right move is to get into a Type 2 audit observation window as soon as possible. Enterprises will sometimes accept a letter confirming you are in-process. They will rarely wait indefinitely.

Get the next post for non-technical owners.

Plain-language compliance guides for founders who are not security people.

EmailSubscribe

What the Compliance Owner Role Actually Looks Like

Here is what often surprises people: the compliance owner's job is about organizing and tracking, not configuring technical systems. You do not need to understand how your engineering team built the infrastructure. You need to make sure the right documentation exists, the right reviews happen on schedule, and the right evidence gets collected when your audit window arrives.

Concretely, the compliance owner does things like:

Running a gap analysis (a review of which required controls you currently have in place and which ones you are missing) so you know where to focus before the audit begins. A gap analysis tells you what documentation you need to create, what processes you need to formalize, and what vendor security reviews you need to get in place.

Maintaining your policy library. Policies are documents that describe how your organization handles security-relevant activities — password requirements, access review schedules, incident response procedures. Someone has to write them, get them approved, and make sure they stay current.

Running quarterly access reviews. You need to confirm, on a schedule, that only the right people have access to the right systems. This does not require technical expertise. It requires scheduling a call, reviewing a list, and documenting the outcome.

Tracking vendor risk. Your enterprise customers care about the security practices of the vendors you send their data to. Managing vendor risk means keeping a list of your vendors, reviewing their security documentation (most of them have their own SOC 2), and documenting that you did the review.

Keeping the evidence file current. During your audit, the auditor will ask for evidence that your controls were operating across the observation period. That evidence is things like meeting notes, access review records, and vendor documentation — organized and accessible.

None of that list requires you to configure a firewall, manage cloud infrastructure, or write a line of code. What it requires is that you stay organized, maintain a calendar, and follow through on commitments your policies describe.

The technical controls — encryption settings, access permissions, logging configuration — are your engineering team's job. The compliance owner's job is to confirm that those controls are in place and documented. That is a very different skill set.

What AI Does vs. What a Human Has to Approve

AI tools like SimpleAudit can do the drafting and the tracking. They cannot do the approving, and they should not.

When you run a Business Impact Assessment — a structured conversation about what level of data loss or downtime your business could actually survive — the AI can guide you through the questions and generate the documentation based on your answers. But someone with authority to speak for the business has to review that documentation and approve it. If you tell the AI that your acceptable downtime is 72 hours but your largest customer would actually leave if you were down for more than four hours, no AI catches that gap. You do.

The same applies to policy writing. The AI can draft a security policy that covers all the right TSC areas. You need to read it, make sure it reflects what your organization actually does, and approve it. An auditor does not care what software generated your policy. They care whether you followed it.

What AI changes is the volume of work that requires expensive human time. The first draft of a policy that used to require a consultant at $200/hour can now be produced in minutes. The gap analysis that used to require a five-figure engagement can now be done interactively. The vendor risk tracking that used to live in a spreadsheet maintained by no one in particular can now be systematic and auditable.

The judgment calls — what is the right retention period for your logs? Should your access review cycle be quarterly or monthly given your team's size? — those still belong to a human. A human who, ideally, has been briefed on what the right answer looks like, which is what this post is trying to do.

Let the AI handle your first SOC 2. Start free trial ->

Start free trial

A 30-Day Plan for Someone Who Is Starting This Week

If you are starting from zero and your first enterprise deal is already in the pipeline, here is a realistic 30-day plan. This is not a comprehensive SOC 2 roadmap. It is the minimum traction you need to have a credible conversation with an enterprise procurement team.

Week 1: Understand what you are being asked for. Read the specific SOC 2 request from your enterprise prospect. Are they asking for Type 1 or Type 2? Type 2 is the one that requires a full observation period (usually 12 months, sometimes 3 months for first-time audits). Type 1 is a point-in-time assessment that some prospects accept as an interim. Understand the difference. Most of the time you want to start the Type 2 window even if you negotiate a Type 1 for the immediate deal.

Week 2: Run your gap analysis. Before you start writing policies, you need to know what you are missing. Work through the core Trust Services Criteria areas — Security is mandatory, and the others (Availability, Confidentiality, Privacy, Processing Integrity) depend on what your product does. For most early-stage companies, Security is the only one that matters. Document what controls you already have and what ones you need to build.

Week 3: Start the policy library. The minimum set for a Security-focused SOC 2 includes an information security policy, an access control policy, an incident response policy, a change management policy, and a vendor risk management policy. You do not need them to be perfect on day one. You need them to exist, be approved by leadership, and reflect what you actually do. Use a tool that can draft them — then read and approve them.

Week 4: Get organized for the audit window. Start your evidence file. Set up calendar reminders for your quarterly access reviews. Collect security documentation from your top vendors. If you are using a platform to manage this, configure it so the reminders are automated and the evidence collection is built into your workflow.

At the end of 30 days, you will not be audit-ready. But you will have a gap analysis, a policy library in draft, and a clear picture of what is left. That is enough to have an honest conversation with an enterprise prospect about your timeline and enough to start a formal audit engagement.

The founders who get stuck are the ones who spend six months convinced they need to understand the technical details before they can take the first organizational step. You do not. The first steps are organizational. You can take them this week.

---

Written by Joe, who led SOC 2 at a prior company before founding SimpleAudit — the AI-guided compliance platform built for founders and owners who don't have a CTO hat to wear.