SOC 2 Before Your First Customer: What Can You Prove?
Can a startup pursue SOC 2 before its first customer? Learn what pre-launch controls can show, how to handle zero-event evidence, and when to wait.
You can start SOC 2 work before your first customer, but a report needs a real service boundary and evidence of controls that actually exist. No customer count automatically qualifies or disqualifies a startup. If you are pre-launch, separate work you already perform from customer-triggered events that have never happened. Then ask the prospective report user and a qualified CPA firm whether your proposed scope, report type, and evidence can answer the request.
Decide whether a report is needed before launch
First ask who needs the report. A prospect may require Type 2 before signing, accept Type 1, or accept a security review while you build a history of control operation. Record the exact service, report type, criteria, and deadline the person will accept. The startup SOC 2 decision guide covers that broader choice.
If no one currently needs a report, you can still establish access rules, review changes, test recovery, and keep records. That work protects the service and gives you evidence if a report later makes sense. A report may be a poor near-term goal if you cannot yet describe a stable service or maintain the controls you propose to examine.
The AICPA’s SOC 2 Description Criteria concern management’s description of a service organization’s system. Its Trust Services Criteria provide the control criteria for the selected categories. Neither source gives startups a customer-count shortcut. Whether your specific service and evidence can support a report is a question for the CPA firm doing the examination.
What can you show with no customers?
Describe the service as it exists today. If the product is in production but has no customer tenants, distinguish that state from a prototype that has not been deployed. List the systems, people, providers, and data inside the proposed boundary. Include real employee, test, and operational data where relevant, without implying that test data is customer data.
Some controls can operate before the first sale:
| Control work | Evidence you may already have | Limit to state clearly |
|---|---|---|
| Workforce access | Identity settings, grants, removals, and access reviews | No customer-user access has occurred |
| Code and releases | Reviewed changes, build results, and deployment records | A test deployment is not a customer release |
| Backup and recovery | Backup configuration and dated restore tests | The restored data may be test or internal data |
| Security response | Alert sources, an approved procedure, and a tested exercise | An exercise is not an actual incident |
| Vendor oversight | Provider inventory, reviews, and approved decisions | Some customer-specific vendors may not exist yet |
Use this as a prompt to inspect your own system, not a universal control list. For each claim, keep the dated record and the source that produced it. A policy that says you review access does not prove that a review happened.
How do you handle customer events that never happened?
A pre-launch service might have no customer onboarding, support tickets, customer data deletion requests, or customer-facing incidents. Do not stage a fake event to fill the file. Record the event source, the period you checked, the query or report used, and the zero count. Keep the fixed result and note who checked it. The audit population guide shows how to support a zero-event set.
Zero events and a control that has never been implemented are different. If a procedure says you will approve every customer access request, a zero-event record can explain why there are no completed approvals. It does not show that the approval path is set up, that staff know who owns it, or that it would work when a request arrives. Test the process where possible, label the test honestly, and ask the CPA firm how it will assess the control.
Does Type 1 or Type 2 fit a pre-launch service?
Type 1 addresses control design and implementation as of a specified date; Type 2 also addresses operating effectiveness over a specified period. That difference matters when your customer activity is sparse. Type 1 still needs a real, implemented control state at the as-of date. Type 2 needs dated evidence across the period for controls that should operate on a schedule or when an event occurs. A period with no customers can still include real access reviews, changes, backup tests, and vendor work. It can also leave some customer-triggered controls unexercised.
Tell the CPA firm which controls have operated, which had no trigger, which were only tested in an exercise, and when the service changed. Ask whether the scope and planned period give the firm a basis to perform its work. Keep any date or period in your own plan labeled as a candidate until the engagement sets formal coverage. The observation period guide explains how to check that evidence path before relying on a Type 2 plan.
Make a pre-launch decision record
Write down the facts before buying software or promising a report date:
- Name the report user and record exactly what it will accept.
- Describe the service that exists now, including its current deployment and data state.
- List each proposed control and mark it as operating, implemented but not triggered, tested in an exercise, or not yet implemented.
- Link each status to its dated source record. For no-event claims, record how you checked the full period.
- Identify the work and cost needed to sustain those controls, then review the proposed scope and timing with a CPA firm.
The resulting choice may be to pursue an examination now, operate the controls while building history, or answer the buyer’s current security questions another way. Management owns that choice. The CPA firm performs the examination and decides what evidence is sufficient.
You can keep this decision and its follow-up work in FileGRC’s Git-native GRC workspace. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. Starter records are proposals to review, not compliance claims. Your identity, cloud, source-control, monitoring, backup, and other systems still operate the controls and produce the source evidence.
Run your SOC 2 program as files in Git.
Keep policies, controls, work, and evidence indexes in a repository your team and agents can inspect.
Frequently asked questions
Can a startup get a SOC 2 report before its first customer?
Having no customers is not a universal ban on a SOC 2 examination. The startup still needs a defined service and controls it can support with real evidence. Ask a qualified CPA firm whether the proposed scope, report type, date or period, and available evidence can support an engagement.
Can a pre-launch startup get a SOC 2 Type 2 report?
A Type 2 report addresses operating effectiveness over a specified period. A pre-launch team may have real internal and service operations to show, but it must not invent customer activity or backfill missing history. A CPA firm must assess whether the scope and evidence support the proposed period.
What if no customers used the service during the SOC 2 period?
Record the actual service state and use an authoritative source to support any zero-event count. Do not create fake customers or imply that a customer-triggered control ran when no triggering event occurred. Discuss the effect on testing and report wording with the CPA firm.
Should a startup pursue SOC 2 before launch?
Start with the report user's requirement, the service you can describe, the controls you can operate, and the cost of maintaining them. If no buyer needs a report yet or the service boundary is changing quickly, building security practices and preserving evidence may be a better current step.
Does FileGRC collect pre-launch security evidence automatically?
No. FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. The team operates controls in source systems and collects their evidence; the CPA firm evaluates it.