Reality Check
You landed a proof of concept with a bigger company. Maybe they want you as a design partner. Then their security team sends an email, and somewhere in it is the phrase SOC 2. You do not have it, and your stomach drops.
A company with SOC 2 can work with a company without it. I sat on the other side of that table as compliance officer at a SOC 2 company, reviewing vendors like you. I never rejected a vendor just for lacking SOC 2. The ones I turned down or sent to manual review had gaps in their paperwork.
What Their Auditor Actually Checks
Most founders miss this: their auditor is auditing your customer, and you are one line in their vendor file.
One of the criteria they are tested against says, roughly, that the company assesses and manages risks from vendors and business partners. In the Trust Services Criteria this sits in CC9.2. The auditor tests whether your customer has a working vendor process, not whether you have good controls.
So when the auditor picks your company as a sample, they ask your customer for:
- An inventory entry: your company in their vendor list, with a risk tier and a reason for that tier.
- A signed contract: with security terms and a DPA.
- A dated review: evidence that someone looked at your security material inside the audit period.
- A next review date: the process repeats.
That is the whole file, and your job is to make it easy to fill. Collecting a document is not enough for them either. Someone has to document a review of it, so give them material a reviewer can work with.
Who Reads Your Pack
Mostly the compliance officer of the bigger company. In a smaller company it may be the CTO, a head of security or someone from legal, but the role is the same: this person owns the vendor process, has to defend every approval to their own auditor, and gets asked "why did you accept this vendor?" months later. I was that person at a SOC 2 company. Nobody in that seat wants to reject you. They want a decision they can write down and stand behind.
So write the pack for them. Use plain, specific sentences, one document per topic, and claims they can check. With a clear file, a reviewer can approve in days. With vague answers they have to chase you, and every chase eats time they do not have.
Which Tier Are You
Most vendor processes sort vendors into tiers, and the tier decides what they ask for. The one I ran looked like this:
- High: you process their customer data at scale, touch sensitive data, or their availability depends on you. SOC 2 or equivalent plus a DPA, but a detailed questionnaire can be accepted instead of the report.
- Medium: a questionnaire, self-attestation or a basic assessment is enough.
- Low: no sensitive data. Standard contract, no review.
Why this matters to you: a proof of concept on synthetic or limited data is often medium rather than high. Scope is your best lever. If you can start without production customer data, say so, and offer that setup in writing. It can move you down a tier.
Reviews repeat too. High vendors were reviewed every year, medium every two years. Expect to be asked again.
This is how one company ran it, and others set their thresholds differently. That is why the first thing to do is ask which tier they put you in.
The Starter Pack
These are the documents I asked for, most decisive first. Prepare them before anyone asks.
1. A Signed DPA
- What to Do: Have a DPA ready, or be ready to sign theirs quickly. It should cover a breach notification window, audit rights, deletion or return of data at the end, how new subprocessors get authorized, and a transfer mechanism if data leaves the EU.
- Why It Matters: No DPA, no deal. The gate I used was simple: no access to systems or data until a signed contract with security terms exists.
2. A Subprocessor List
- What to Do: List every subprocessor by name, with its purpose and country.
- Why It Matters: "Leading cloud providers" is not a list. The reviewer needs names to check where the data goes.
3. Encryption, Specifically
- What to Do: Write down how data is encrypted at rest and in transit: which service, which mechanism, which protocol version.
- Why It Matters: "Industry standard encryption" tells the reviewer nothing. A named service, mechanism and protocol version gives them something to check.
4. Access Control on Your Plan
- What to Do: State whether MFA, SSO and RBAC are available on the plan they are actually buying. Also describe how your own team signs in.
- Why It Matters: Reviewers check the plan, not the feature page.
5. Data Location
- What to Do: One sentence: where the data is stored and processed.
- Why It Matters: It is one of the first questions, and an unclear answer stalls everything after it.
6. Incident Response and Backups
- What to Do: A one-page summary of each: how you detect and handle an incident, how fast you notify customers, how often you back up, and when you last tested a restore.
- Why It Matters: Together with encryption at rest, encryption in transit and access control, these were the five baseline measures I mapped every vendor against.
7. AI and Training Data
- What to Do: State explicitly that customer data is not used to train models, and name every LLM provider you send it to.
- Why It Matters: This became a standard question fast. Silence here reads as a yes.
8. Public Material
- What to Do: A security page or short whitepaper, a privacy policy and terms. Optionally, a penetration test summary.
- Why It Matters: I started every review by gathering what was public. A good security page answers half the questions before they are asked.
How Strong Is Your Evidence
The reviewer weighs what you send. An independent report like SOC 2 or ISO 27001 is the strongest. A detailed whitepaper or a technical annex to the DPA is medium. Generic marketing claims are weak, and they are not enough on their own. Without a report, aim for the middle: specific, written, signed.
The Questionnaire
Without a report, the usual substitute is a vendor security questionnaire plus a signed DPA. The one I used covered company information, personnel screening, access control (MFA, offboarding), devices and disk encryption, data handling, remote work, incident response and breach notification, privacy compliance, business continuity, references, and a signed attestation at the end.
How to answer well:
- Answer what you do today. Not what you plan. Mark planned items as planned, with a date.
- Be specific. Name the tool, the setting, the frequency.
- "No" is allowed. A "no" with a reason and a mitigation is reviewable. A vague "yes" is a red flag the moment someone checks.
- Remember the signature. The attestation makes your answers a statement your company stands behind. Write them as such.
- Reuse. Keep your answers in one document. The next customer will ask the same questions.
What Makes a Reviewer Nervous
These pushed vendors into manual review or conditional approval:
- No DPA, or reluctance to sign one.
- Refusing to exclude customer data from model training.
- Security features that exist only on a higher plan than the one being bought.
- Generic encryption claims.
- A missing or generic subprocessor list, or LLM providers that are not on it.
- An unclear role: is the vendor a processor or a controller of the data?
You can fix most of these with a document. None of them needs an audit.
What to Say About SOC 2 Itself
If you have all of this in place, you have already done a good part of the groundwork for your own SOC 2. The policies, the vendor list, the access and encryption evidence and the incident process are what an auditor asks for later, so the week was not wasted.
If SOC 2 is on your roadmap, tell them when, and which stage you are at. If you have started or want to, I wrote about how to begin in SOC 2 for a Team of 4. In the process I ran, a report in progress could become a dated condition, for example to close within about 30 days. Do not promise a date you cannot keep. It goes into their vendor file as a condition, and someone will check it.
