How to answer a security questionnaire before you have SOC 2

Answer the certification question without hedging

A SOC 2 examination is a CPA assurance service concerned with controls relevant to security, availability, processing integrity, confidentiality, or privacy. If your company has not received the relevant report, answer the certification question with a clear no. Readiness work, a control checklist, a penetration test, or an audit scheduled for later is not a completed SOC 2 examination.

A precise no is more useful than language such as in progress, compliant by design, or aligned with SOC 2 when those phrases leave the buyer unsure about what exists. If an examination is genuinely planned, state the current stage and target date separately. Qualify the date as a plan that may change, and name the report type only when the decision has been made with the auditor.

The certification question is only one line in the review. The remaining questions usually concern present practices: who can access production, how changes are reviewed, how customer data moves, how incidents are handled, and whether recovery arrangements have been tested. Those questions can be answered before SOC 2 when the company has current, reviewable evidence.

Keep these two statements separate. One describes independent assurance you do or do not hold. The other describes how your systems and processes work today. Combining them encourages the reader to infer more assurance than the company has.

Set the scope before collecting documents

Write a one-page scope note before opening the spreadsheet. Record the legal entity, product, production environment, hosting regions, customer-data categories, and date at which the answers are accurate. Add any material exclusions, such as a beta feature that uses a different provider or a customer-managed deployment that follows a separate process.

Scope prevents a true statement about one system from becoming a false statement about the whole company. For example, multi-factor authentication might be enforced for the primary cloud account while a legacy support tool follows a different identity process. An unqualified yes would hide the exception. A scoped answer can describe the main control, identify the exception, and record the work needed to resolve it.

Use the security questionnaire evidence checklist to inventory the material behind recurring answers. The checklist is intentionally organised by buyer question and proof type, so a small team can start with the active deal rather than attempt to build an entire compliance programme in one week.

Assign one accountable reviewer for each answer domain. Engineering may confirm infrastructure facts, the privacy owner may confirm data-use wording, and the founder may approve commercial commitments. One person should still own the final response package and make sure those inputs use the same scope and cut-off date.

Build a minimum evidence packet

The NIST small-business CSF resources provide a practical starting point for organisations with modest cybersecurity plans. For a live buyer review, translate that broad risk-management work into a compact packet that supports the questions actually being asked.

Do not upload every internal document to the buyer. First create a private working packet for your reviewers. Then decide which items can be shared publicly, which require a confidentiality agreement, and which should only be summarised. A system configuration or internal incident record may support an answer without being suitable for external distribution.

• A current architecture and data-flow description showing the product boundary, hosting providers, integrations, and sensitive data stores.
• Access-control, secure-development, change-management, incident-response, backup, retention, privacy, and supplier-management policies that match actual practice.
• Operational records such as a recent access review, backup restoration result, vulnerability report, incident exercise, and approved production change.
• A current subprocessor register stating which providers receive customer data, for what purpose, in which locations, and under which contractual safeguards.
• Approved product statements covering encryption, deletion, authentication, logging, support access, data use, and AI providers where relevant.
• Independent material that genuinely exists, such as a penetration-test summary, certificate, or audit report, with its product scope and assessment period recorded.

Match each answer to the evidence it actually has

For every question, write the claim in a small, testable form. Record the exact source, relevant passage or observed value, scope, owner, review date, and limitations. Reviewers can then decide whether the evidence supports yes, no, partial, not applicable, or clarification required.

A policy proves that an approved requirement was documented. It does not prove that the process operated effectively throughout a period. A screenshot or read-only integration can show a setting at a stated time. It does not establish continuous operation unless the check actually runs over time and detects change.

Use plain assurance labels in the working record. Self-declared means an authorised person has confirmed a fact without attached proof. Document-supported means an approved source contains a relevant passage. Human-verified means a reviewer has assessed the claim, scope, citation, and currency. System-verified means a read-only check observed the relevant state at a stated time. Independently audited applies only within the external assessor's defined scope and period.

The answer sent to the buyer does not need to contain this internal vocabulary, but it should preserve the same limits. Wording such as documented in our approved policy, observed on 18 July 2026, or covered by the report for the stated period tells the buyer what basis they are evaluating.

Use partial answers instead of forced yes answers

CISA's vendor supply-chain template for smaller businesses explicitly supports yes, no, and partial responses. That is a useful discipline even when the buyer's spreadsheet only provides a yes or no field.

When reality is partial, select the closest accurate option and use the comments field to describe the implemented scope and the exception. If the form does not permit clarification, ask the buyer how it wants exceptions supplied. Do not convert partial into yes because the narrative box is inconvenient.

A useful partial answer contains four parts: the control that exists, the population or system it covers, the exception, and the next decision or remediation step. Avoid a lengthy security essay. The buyer needs enough information to assess the residual risk and decide whether follow-up evidence is required.

Do not offer a roadmap date merely to make the answer look stronger. Give a date only when the work is approved, owned, and realistically scheduled. A proposal under discussion is not a commitment.

Turn unsupported questions into owned gaps

When the evidence is missing, stale, contradictory, or outside scope, stop drafting. Record the buyer question, unsupported claim, affected product, required evidence, accountable owner, due date, and commercial importance. The gap should remain visible until the underlying practice or proof is resolved.

A governed security questionnaire automation workflow should help with intake, retrieval, citations, and routing while preventing unsupported text from becoming an approved answer. Fluent language cannot replace a missing access review or backup test.

Prioritise gaps by buyer impact and security consequence. A missing document title may be quick to fix. A privileged-access exception or an untested recovery process may need engineering work and a risk decision. The active deal helps set urgency, but it should not cause a reviewer to approve a claim that the evidence does not support.

Once the control or proof has been reviewed, create a reusable approved claim with its citation and limitations. The next questionnaire can begin with a stronger source of truth rather than another copy of the original spreadsheet.

Prepare a buyer-ready response package

Before sending the file, review it as one document. Search for inconsistent dates, product names, encryption descriptions, retention periods, subprocessor counts, and certification language. Check that every attachment matches the scope stated in the answer and that no internal-only material has been included by mistake.

Add a short cover note. State that the company does not currently hold a SOC 2 report, if that remains true. Identify the product and date covered by the response, describe the types of supporting evidence available, and provide a controlled route for follow-up questions. If an examination is planned, separate that plan from the current assurance state.

Record who approved the final package and retain the exact version sent to the buyer. When a source changes later, reviewers need to know which previous answers depended on it. This history also helps explain why wording was changed instead of silently replacing an earlier commitment.

The objective is not to imitate a mature compliance department. It is to give the buyer an accurate view of current security practices, the proof behind them, and the limits that remain. That is a credible basis for a trust decision before an independent report exists.