A Customer Asked for SOC 2. What Evidence Can You Provide Now?

A GitHub snapshot is not a SOC 2 alternative. If a customer asks for SOC 2 and you do not have a report, first clarify whether they require the actual report, evidence for a particular underlying control, or another form of assurance they are willing to accept.

Then state your current position accurately, map the evidence you genuinely have, and identify what is missing. Preparation evidence can help you answer a buyer and organize future work. It does not become a SOC 2 examination or report merely because it is collected in a folder or questionnaire.

The useful rule is simple: understand the ask, find the proof, and do not overclaim. The buyer's own questionnaire, procurement requirement, contract language, or direct clarification remains authoritative for that buyer.

What might the buyer actually mean?

“We need SOC 2” may be shorthand for different requests. Do not infer which one applies. Ask the buyer questions such as:

• Do you require an actual SOC 2 report?
• Which report, scope, or service is relevant to this request?
• Is the requirement connected to a particular product or system?
• Are you primarily asking about one or more specific controls?
• Will you accept other evidence temporarily while the requirement is clarified?
• Is this a procurement policy, a contract requirement, or part of a broader security review?

A buyer may accept a bounded answer to a control question, or the buyer may require a formal report regardless of the other evidence you provide. Only the buyer can resolve that distinction for its own process.

What SOC 2 does and does not mean

The AICPA SOC 2 overview describes a SOC 2 examination as a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. The relevant scope is the service organization, its systems, and the controls addressed by the engagement; it is not a generic label for every security practice a company may have.

That distinction matters when a buyer uses the phrase “SOC 2” beside individual questions about access, changes, incidents, backups, encryption, or vulnerabilities. Those questions may need their own evidence even when a report exists, and a useful answer to one control question is not a report.

Formal examination versus preparation evidence

Collecting evidence can make a future review more organized. It cannot promise an examination outcome, establish every control, or turn missing evidence into proof.

What evidence might you have now?

Start by classifying the source rather than treating every file as equally strong. The useful categories are:

Not every claim needs every evidence type. The buyer's question, the systems in scope, and the evidence's freshness determine what is relevant. A policy may be the right source for intended responsibilities; an operating record may be the right source for whether a recurring process occurred.

Example evidence map: question, support, limitation

These examples are ways to reason about a request, not universal proof rules. Keep the buyer's wording and your checked scope beside each answer.

Weak or incomplete evidence is still a scope problem

Common mistakes include:

• A policy is treated as proof that the process operated.
• A screenshot from one account is treated as universal coverage.
• A cloud or identity-provider feature is treated as proof it is enabled and correctly configured.
• GitHub configuration for one repository is treated as a company-wide control.
• An old artifact is used without checking whether it reflects current operation.
• A public repository observation is used to make a claim about private systems.
• A questionnaire answer copied from last year is assumed to describe today's environment.
• Evidence preparation is described as a SOC 2 report or examination.

Use honest answer states

Use the state that matches what you can support: available, needs confirmation, partially implemented, not currently available, not yet implemented, not applicable when genuinely outside scope, or requires clarification from the buyer.

Missing evidence is not automatically negative evidence. It does mean that you should not replace the gap with a stronger claim. Keep the unresolved point visible, name who can confirm it, and say what source or review would close it.

What if the buyer really requires the report?

If the buyer confirms that an actual SOC 2 report is mandatory, GitHub evidence, questionnaire preparation, and Diligence Rescue cannot substitute for it. Formal SOC 2 work requires the appropriate qualified professionals and examination process for the requested scope.

Vauntico can help a founder interpret the request and organize available evidence around it. Vauntico does not perform SOC 2 examinations, issue SOC 2 reports, certify a company, provide compliance counsel, or replace an auditor or specialist.

What public GitHub evidence can and cannot show

A public GitHub snapshot can provide bounded, point-in-time public engineering context. It may help a founder explain the narrow public source that was observed, but it is subordinate to the buyer's actual requirement. It is not an audit-preparation replacement.

Public GitHub evidence does not prove:

• private repository configuration or private access controls;
• production infrastructure or company-wide MFA;
• internal incident history or organizational policies;
• control operation over time;
• SOC 2 compliance, a SOC 2 examination, or a SOC 2 report; or
• universal company controls.

If public context is useful, the public GitHub snapshot is a bounded supporting input only. It should never be presented as a certificate, formal diligence package, or substitute for the evidence the buyer requires.

A practical response sequence

1. Copy the buyer's exact wording, including any questionnaire or contract context.
2. Identify whether it asks for an actual report, evidence for a particular control, or both.
3. Mark scope words such as service, product, environment, system, all, current, and time period.
4. State the company's actual current status without upgrading a partial or unverified answer.
5. Map the evidence that genuinely supports the specific question.
6. Mark anything that needs confirmation, a better source, formal review, or buyer clarification.
7. Ask the buyer what alternatives, if any, they accept when a report is not available.
8. Do not present preparation evidence as a formal examination or report.
9. Escalate to an appropriate auditor or specialist when the requirement actually demands formal work.

Useful reference

The AICPA SOC 2 material supports the narrow terminology used here: a SOC 2 examination is a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. It does not prescribe one universal preparation artifact for every buyer or prove your particular implementation.

A careful answer is not the answer that sounds most mature. It is the answer whose scope, source, and uncertainty a buyer can understand.