A Customer Asked for SOC 2. Start With the Evidence Request.

Get the customer's requirement in writing

Record the customer's request in its own words. Confirm the report type, product or service being evaluated, deadline and acceptance contact. Ask whether the request is a condition of contract signature or an initial due-diligence question. A procurement request and an internal sales target carry different consequences.

Ask which interim evidence the customer will review while preparation proceeds. A current policy set, assessment or remediation plan might support a conversation, but acceptance belongs to the customer. Obtain its response before representing an interim document as sufficient.

Use a short requirement record:

Do not convert a target date into an assurance commitment before the CPA firm confirms its scope and scheduling.

A Type 1 report addresses the system description and suitability of control design at a specified date. A Type 2 report also addresses operating effectiveness throughout a specified period. [3] Ask the customer which it needs before paying for an interim report. The SOC readiness service → explains the report types and criteria; the customer's acceptance requirements should guide the discussion with the CPA firm.

Define the service before collecting documents

Document what the service does, the information it handles, its principal systems and the organizations sharing responsibility. Include production environments, relevant supporting activities and significant dependencies. Keep the proposed boundary connected to the product the customer is buying.

AICPA's description criteria support preparing and evaluating a service organization's system description. Its public resource page explains this purpose; the full download requires a free account. [2]

The practical output is a scope record covering the product, customers, environments, dependencies, responsible teams and unresolved boundary decisions. Review it with the readiness adviser and CPA firm. A working scope record gives them useful context; their engagement decisions still need confirmation.

Give each evidence request an owner

Build an evidence register with the control area, responsible owner, requested record, relevant period, storage location and review status. Start with material already in use: access approvals, change records, incident records, vendor reviews, policies and management decisions.

Check whether each record relates to the agreed service and period. An access review for one application does not automatically support every application. A completed procedure document describes expected activity; a dated review and its exception decisions show what occurred.

Preserve the record's origin and context. Keep exports with their source, collection date and relevant scope. Restrict access to sensitive evidence. Treat missing records as gaps to resolve through future operation and documented remediation. Never backdate approvals or reconstruct a record as if it existed during the original period.

Turn gaps into decisions

For each gap, write the observed condition, business consequence, proposed action, owner and dependency. Identify the evidence needed to support closure. A completed ticket and a tested control answer different questions, so make the closure expectation explicit.

Separate work your team will perform from support included in the readiness engagement. Keep the CPA firm's examination activities and scheduling visible as separate dependencies. This prevents one deadline from concealing several distinct pieces of work.

For example, a review identifies missing access approvals. The immediate response is to confirm the affected population, evaluate current access and establish the approval workflow with its owner. The historical gap remains part of the record; later evidence demonstrates subsequent operation. This is an illustrative situation, not a Cyvelle client result or an audit conclusion.

Build the date from separate milestones

Keep preparation, the Type 2 observation period, examination fieldwork and report issuance visible as separate milestones. Record an owner, dependencies and confirmation status for each. Ask the CPA firm to assess the proposed period and available evidence before treating dates as agreed. Its capacity and review process also affect when a report can be issued.

The observation period is the period covered by the examination, not the time spent preparing or the dates of the auditor's fieldwork. A tool subscription or readiness kickoff does not establish that controls operated throughout that period. If the plan changes, revisit the customer's deadline and agreed interim evidence rather than promising that the remaining stages can be compressed.

Budget for the work around the examination

Compare proposals against the same service boundary, report type, criteria and period. Build a budget with separate lines for:

Readiness advice and the deliverables included in that engagement

Remediation work, including internal engineering, IT, HR and management time

Security tools and any evidence platform, including setup, integrations and recurring subscriptions

The independent CPA firm's examination and report

Continuing control operation, evidence collection and later reporting needs

For each line, record the responsible team or provider, whether the amount is a quote or an estimate, the assumptions and whether the cost recurs. Check bundled proposals for overlapping charges and excluded work. Assess a platform against your actual systems, export needs and ownership model before committing to it; buying software does not replace operating controls or the independent examination.

Reserve capacity for unresolved gaps and changes to scope. Discuss additional testing, specialist advice or implementation separately where needed. Readiness pricing covers the agreed readiness engagement; it should not be treated as the total cost of obtaining and maintaining the assurance your customer requests.

Leave the first management review with clear decisions

Agree the proposed scope, assign open items and decide what the customer will receive next. Record who will confirm the CPA firm's requirements and when management will review progress. Report evidence gaps plainly, including unresolved questions.

A responsible readiness plan connects the requested assurance, operating controls, evidence and external examination. It avoids unsupported promises about the opinion or the customer's acceptance.

Keep report communications within their limits

Before sending a SOC 2 report, check its restricted-use language and intended recipients with the CPA firm. AICPA describes specified users with sufficient knowledge to understand the report. [4] Confirm sharing approval and any confidentiality terms; an NDA does not itself establish that a recipient is an intended user.

In customer replies, RFPs or a security-page summary, identify only the report type, service or system, criteria and date or period actually covered. Keep relevant qualifications visible. Do not imply that unrelated services are covered or that the report guarantees security or buyer acceptance. Use an approved summary and report-request route for public communications. Vendor Security Questionnaire Support → explains the evidence index, permitted recipients and controlled sharing.

Your next step

Bring the customer's request, proposed service boundary, existing evidence and deadline to a readiness discussion. Review our SOC 2 Readiness service → then Book a Free SOC 2 Strategy Call to discuss the starting scope.

Sources

1. AICPA & CIMA — System and Organization Controls: SOC Suite of Services

2. AICPA & CIMA — 2018 SOC 2 Description Criteria, with revised implementation guidance

3. AICPA — SOC 2 Reporting on Controls at a Service Organization, Chapter 1 excerpt

4. AICPA — SOC 2 Reporting on Controls at a Service Organization, Chapter 1 excerpt