Your buyer asks for SOC 2. You don't have one. What should you say?

Updated October 2026 · Guidance for small B2B software vendors

Don't invent a report or tick “Yes” to move procurement forward. A SOC 2 report is the output of a professional examination of an organization's relevant controls; a policy document, pen-test report or a screenshot is not the same thing. But a buyer may be willing to assess alternative evidence, depending on its own procurement rules.

1. Answer the actual question

If asked “Do you have a current SOC 2 Type II report?”, answer “No” when that is the truth. If you are preparing for an examination, state the real status and whether there is a credible target date—not a guaranteed certification date. Never say “SOC 2 compliant” based only on your own checklist.

2. Ask whether alternative evidence is acceptable

A buyer might accept a defined package of evidence, might require a specific independent report, or might decide not to onboard the vendor. Ask the buyer's security team directly what exceptions, alternate reports or contractual protections it will consider. Don't imply that every buyer will waive a SOC 2 requirement.

3. Gather what you can actually prove

Useful evidence categories often include:

• Governance: current and approved security policies, named control owners, dated risk assessments.
• Access: MFA configuration, access review examples, employee offboarding procedures.
• Application and infrastructure: testing summaries, patch records, cloud-hosting boundaries, change approvals.
• Resilience and response: incident-response plan, tested restore records, customer-notification terms.
• Privacy: current DPA, retention rules, subprocessor disclosures when relevant.

Only claim that a control exists if it is actually implemented. A written policy alone is not proof that a process operates effectively.

4. Don't send sensitive evidence in a first email

Check the buyer's authorized secure evidence-sharing channel and any confidentiality requirements. Consider redaction, access controls and document expiration. Never post private architecture, configuration secrets or employee records publicly to “prove” security.

5. Build a response and exception register

For each buyer question, record the owner, available evidence, truthful proposed answer, remaining gaps and approval status. Keep “Needs review” and “No evidence” separate from “Yes.” This prevents accidentally submitting unsupported AI-generated assertions.

Further reading

AICPA: SOC 2 resources · NIST: Small Business Cybersecurity Quick-Start Guide