Customer asked for SOC 2 before you have one: options

What to send a customer when they ask for SOC 2 before you have one

No SOC 2 report can exist until an independent CPA firm examines your controls, so a deal that requires one today is usually answered with two things: independent evidence that your security program already works, and a firm, written commitment to an examination date. The mix you send depends on three things: which regulator, if any, sits behind the customer, what the contract actually says about the report, and how sensitive the data you will handle is. A bank's third-party team will weigh these differently from a mid-market buyer. Start by asking the customer's security or vendor risk team exactly which assurance they will accept, whether a Type 1 report, a Type 2 report, a bridge letter or a substitute, and whether the wording says "SOC 2" or "an independent attestation of equivalent scope." Get that answer in writing before you build the package.

The division of labor matters because the customer will ask who vouches for what. Your organization owns its controls and the decisions behind them. DeployOpen, as an implementation partner, can prepare systems, configuration, policies and evidence so the controls are visible when an examiner arrives, but DeployOpen does not issue audit reports, attestations or certifications. Only the CPA firm issues a SOC 2 report. A Type 1 report contains a description of the service organization's system and the CPA's opinion on whether that description is fairly presented and the controls are suitably designed as of a specified date. That is a point-in-time document, so it shows design, not sustained operation. When you propose a Type 1 date, confirm with the CPA firm that the date, scope and readiness work are realistic before you put them in a contract, and avoid promising a report date you do not control.

Which interim assurances buyers accept

When a deal needs SOC 2 and no report exists yet, buyers usually look for some independent or structured evidence of security in the meantime. The options below differ sharply in who produced them and what they can prove, so none of them should be treated as a substitute for a report without a buyer's explicit agreement.

Independent ISO/IEC 27001 certificate

A certificate issued by an accredited certification body after an audit of an information security management system. It shows that an independent party tested a documented management system at a point in time and that the scope named on the certificate was covered. It does not cover systems outside the stated scope, and it does not show that controls operated over a period. Check the certificate scope, its validity dates, and the accreditation of the body that issued it.

Recent penetration test report

A report from a qualified tester who tested your application, APIs or infrastructure using a documented method. NIST SP 800-115 describes a method for planning and reporting security testing and is a useful reference for what a sound report should contain. The report proves that a test happened and what it found on the tested scope at that time. It does not prove that the findings were fixed, that controls are designed well, or that the tester was independent of the team that built the system. Ask for the scope, the test dates, the tester's qualifications, and the remediation status of each finding.

CSA STAR Level 1 self-assessment

A free self-assessment in which your organization completes the Consensus Assessments Initiative Questionnaire, CAIQ v4, and lists the result in the public STAR Registry, which is updated annually. It shows that you have answered a standard set of cloud security questions in public, which can reduce repeated questionnaires. It is not independent because the company writes the answers, and no third party has verified them at Level 1. Buyers will still check whether the answers match your actual controls.

Completed customer security questionnaire

A response to a buyer's own questionnaire, typically covering access, encryption, logging, incident response and vendor management. It proves what you stated about your controls for that buyer, and its value depends on how precise and evidenced the answers are. It is not independent, and a questionnaire answered once does not show that controls operated over time. Keep a master answer set, attach evidence where you can, and avoid answers you cannot support in an audit.

Bank third-party due diligence file

The package a bank gathers when assessing a vendor, which may include contracts, financial information, business continuity documents and the assessments above. US banking agencies' 2023 interagency guidance says a bank may consider reviewing a third party's SOC reports and independent certifications during due diligence. Each bank decides what it accepts, so ask the bank's third-party risk team early which documents it will use and whether a bridge letter or Type 1 date is acceptable.

What banks and regulated buyers look for in the meantime

US banking agencies do not require a particular assurance report from their vendors, but their 2023 interagency guidance on third-party relationships says a bank may consider reviewing a third party's SOC reports and independent certifications during due diligence (Federal Register notice, 88 FR 37920). For a company without a report, the practical point is that the bank decides case by case. Ask the buyer's third-party risk team, in writing, which interim evidence they will accept before you commit to a timeline, and record the answer alongside the deal file so procurement and the bank's reviewers work from the same position.

The September 2026 proposed Federal Reserve guide for community banks (91 FR 58438) is still a proposal, not final guidance, but it is a useful signal of what examiners may expect. It lists penetration testing reports alongside SSAE 18 SOC reports and other independent assessments, such as PCI DSS, NIST and ISO reports, as evidence a bank may rely on. A recent penetration test performed by an independent tester, covering the production application and its APIs, is therefore a candidate for the interim pack. Confirm with the bank that the test scope, date and retest results meet its own minimum, since a report that covers only a staging environment or is several releases old is unlikely to carry weight.

Plan the interim pack as a set of documents you can defend, not as a substitute for a report. A typical pack names the independent assessments you hold, a current system description, your security policies, and a dated list of remediation items with owners. Do not describe a Type 1 date as a report, do not offer a SOC 2 logo or trust page badge before an auditor has issued an opinion, and do not promise that a report will be issued by a particular quarter unless your CPA firm has committed to that date in writing. Any date you give should be treated as a target that depends on the auditor's engagement terms and the readiness of your controls.

How to commit to a Type 1 date without overpromising

This sequence turns a customer's request into a dated plan that rests on a confirmed system boundary, a documented gap check and a signed examination engagement, so the date you share reflects work you have actually scoped. It also makes clear what a Type 1 report does and does not cover.

Confirm the scope and system boundary
Start by deciding which product, environments, data flows and support functions the report will describe. Write down the in-scope services, the hosting and subservice organizations, and the security category, and state explicitly that security is always in scope while availability, confidentiality, processing integrity or privacy are added only if the customer's need requires them. Engineering leadership and the commercial owner should both sign off. The output is a one-page system boundary statement that the CPA firm can review before any fee discussion.
Run a readiness gap check against the common criteria
Map your current controls to the common criteria CC1 to CC9, which apply to every SOC 2 report. Walk each criterion, record whether a control exists, whether it is written down, and whether there is any evidence it runs. Include access reviews, change management, vulnerability handling, incident response and vendor management. The output is a gap register listing each missing or undocumented control, its owner and the artifact needed to close it. This check tells you what you can honestly commit to, rather than what you hope to have ready.
Close gaps and assemble the control matrix
Assign each gap to a named owner and fix it in the environment, not only on paper. Policies should describe what the team actually does, and each control should point to the evidence that proves it ran. Compile these into a draft control matrix that links criteria, controls, owners and evidence sources. The output is a control matrix plus a short list of any controls still open, so the remaining work is visible to everyone who will be asked about the date.
Agree the examination engagement in writing
Ask one or more CPA firms to scope a SOC 2 examination against your boundary and the report type you intend to request. Compare engagement letters, including who performs readiness work, what the firm will test, what they need from you, and how fieldwork and reporting dates are set. Note that an independent CPA firm issues the report and that DeployOpen, or any implementation partner, prepares systems and evidence but does not attest. The output is a signed engagement letter that states the Type 1 as of date and the scope agreed in step one.
Set the report date as the assessment point
Under a Type 1, the auditor evaluates the system description and whether controls are suitably designed as of a specified date. Choose that date only after the gap register is closed for the in-scope controls, and confirm it with the CPA firm. Be clear internally that a Type 1 does not test whether controls operated over time, so a Type 2 requires a separate observation period that you should describe as a later step. The output is a documented as of date and a note on what the Type 1 will and will not say about operating effectiveness.
Share a dated plan with the customer
Send the customer a written plan containing the system boundary, the report type and as of date, the CPA firm's engagement status, the open items and the point at which a report would be available. Use the firm's confirmed dates, not estimates, and avoid promising that the report will be clean or that a Type 2 will follow on a fixed schedule. Ask the customer which evidence they will accept in the meantime, such as an independent certification or a recent penetration test report. The output is a dated plan the customer has acknowledged in writing, with the open risks listed.

What a SOC 2 Type 1 or Type 2 costs and who gets paid

This table shows who is paid for each part of a SOC 2 Type 1 or Type 2 effort, whether the cost is one-time or recurring, and what pushes it up. The only published audit fee ranges come from the Justice Department's October 2024 proposed rule, which cited vendor estimates of $5,000 to $25,000 for Type 1 and $30,000 to $100,000 for Type 2; those are estimates that vary with scope, so ask every firm for a written quote against your system boundary.

Cost component	Who is paid	One-time or recurring	What drives it
CPA firm examination fee	The CPA firm that issues the report	Type 1 is one-time; Type 2 repeats each audit period	System scope, number of criteria categories, sample sizes, and observation period length
Readiness or implementation partner	A consultant or partner who prepares controls and evidence	Usually one-time setup, with optional retainers afterward	Current maturity, number of systems in scope, and whether policies already exist
GRC or tooling subscriptions	Software vendors, or your own hosting costs if self-hosted	Recurring, usually annual or per seat	Number of users, integrations, and whether you run open-source tools yourself
Internal staff time	Your own employees (no external invoice)	Recurring across the audit cycle	Access reviews, evidence collection, change tickets, and incident handling
Penetration test	An independent security testing firm	Typically annual, and often required before the report	Application and infrastructure scope, retest rounds, and whether a bank customer requests the report
Bridge letter, if needed	Usually your own team with input from the CPA firm	One-time per gap period	Length of the gap between the audit period end and the customer's request date

What not to promise a customer

Deals under pressure produce promises that the audit process cannot keep. Each card below names one promise, explains why an assessor, bank or regulator will push back, and offers wording you can use instead. The Journal of Accountancy published a February 2026 piece on fast and easy SOC promises, so buyers are already scrutinizing claims like these.

A report in a fixed number of weeks

A SOC 2 report depends on controls that have been designed, put into operation and, for Type 2, operated over a period. Your auditor sets the fieldwork schedule, and evidence cannot be backdated to fit a sales date. Before you commit to any date, confirm with your CPA firm what it needs from you and when. Replace the promise with: "We will start the examination on [agreed date] and share the readiness timeline once our CPA firm confirms fieldwork dates."

A guaranteed clean opinion

The auditor forms the opinion, not you or your consultant. An exception in testing can lead to a qualified opinion, and nobody controls the result in advance. Promising a clean report signals that the vendor does not understand how the examination works. Replace the promise with: "Our controls are designed to meet the criteria in scope, and we will share the report, including any exceptions, under the NDA terms agreed with you."

A report banks must accept

US banking guidance says a bank may consider SOC reports during due diligence, which is a judgment the bank makes, not a rule that binds it to accept a particular report. Community bank guidance proposed in September 2026 also lists penetration testing reports and other independent assessments as things a bank may rely on. Replace the promise with: "We expect the report and our other assessments to support your third-party review. Your team decides what it accepts, and we will answer follow-up questions on scope."

Implementation partner issues the report

Only an independent CPA firm issues a SOC 2 report. An implementation partner can prepare systems, controls and evidence, but it cannot sign or attest to the results. Saying the partner will certify you blurs roles that customers and assessors check closely. Replace the promise with: "Our implementation partner prepares the controls and evidence. [CPA firm name] performs the examination and issues the report."

A STAR listing equals SOC 2

STAR Level 1 is a free self-assessment using the CAIQ v4 questionnaire, listed in the public STAR Registry and updated annually. It is not an independent examination and does not replace a SOC 2 report. Customers may accept it as a standard answer set, but they will still ask what you have independently tested. Replace the promise with: "We have completed a STAR Level 1 self-assessment, and our SOC 2 examination is planned for [agreed period]. Until the report is issued, here is what we can share."

Writing the interim commitment into the contract

Write the interim commitment as a dated, specific obligation rather than a general promise of compliance. The clause should name the examination type (SOC 2 Type 1 or Type 2), the Trust Services Criteria categories in scope, the CPA firm that will perform the examination if it is already engaged, and the date by which you expect the report. Describe the interim evidence the customer will receive in the meantime, such as a penetration test report, an independent certification or a CSA STAR self-assessment, and state that these are provided as current evidence of controls and not as a SOC 2 report. Confirm each item with your CPA firm before signing, because an auditor's timetable depends on fieldwork and client readiness, and the firm, not your sales team, should set the target.

Name the document the customer receives. A SOC 2 report is generally restricted use, so the contract should say whether the customer gets the full report under an NDA and who may read it, while a SOC 3 report is a general use report that can be freely distributed and is often used for public trust pages. Decide which of these you can deliver and when, and write that into the agreement. Then state what happens if the audit slips: the notice you will give, the interim evidence you will refresh, whether fees or service credits apply, and whether the customer may terminate. Ask legal counsel to review these terms against your own risk position, since the remedies you accept determine your exposure.

A bridge letter is a later option to discuss with your CPA firm, not a substitute for the commitment itself. Whether one is appropriate, and what it would state, depends on the period between the end of your examination window and the date you can give the customer a report. Ask your auditor to confirm the form of any such letter and whether your customer's contract should reference it. Until that conversation happens, do not describe a bridge letter in the contract as a deliverable.

What changes the answer for your organization

The right interim answer depends on what your SOC 2 will cover, where the system boundary sits, and who your customer answers to. The cards below cover the factors that move the answer, how to control each one, and what changes when you do.

Scope: security only or added categories

A SOC 2 always includes the security common criteria, CC1 to CC9. Availability, confidentiality, processing integrity and privacy are added only when they are in scope. A buyer who asks for a specific category, such as confidentiality for sensitive financial data, will not accept a security-only report as an answer. Before promising anything, confirm with the buyer which categories their due diligence expects, then agree the scope in writing with your CPA firm. Adding a category later means extra criteria to evidence and a wider report.

System boundary and data flows

The system description defines which infrastructure, software, people and data are in the examination. A narrow boundary is easier to evidence, but a buyer will test whether it covers the component that actually touches their data, such as an API gateway, a support tool or a backup store. Draw the boundary with data flows before you talk to the buyer, and list what sits outside it along with the reason. Anything excluded should be something the buyer can accept, not something they will discover in review.

Hosted versus self-hosted delivery

If you operate the software for customers, your controls cover production access, patching, backups and monitoring, and the auditor tests them. If customers run the software in their own infrastructure, you are not operating that environment, so the report may cover only what you run: support tooling, the build pipeline, update delivery and any hosted components. Confirm which of these applies before you describe your environment. A buyer who expects hosted controls and receives a report about a build pipeline will ask hard questions, so state the delivery model clearly in your first reply.

Number of third parties

Cloud providers, identity platforms, support desks, email services and code hosts each affect the answer. A subservice organization that holds customer data is usually carved out and represented by its own SOC report, and a bank will ask for those reports as well. Build a list of every third party that touches customer data, collect the SOC reports or equivalent assurance you can get from each, and note any gaps. A long list with missing reports weakens an interim answer more than a short list with clear coverage.

Evidence maturity

A Type 1 report tests whether controls are designed suitably as of a date. A Type 2 report tests operating effectiveness over a period, so the control has to have run, and left evidence, for the whole observation window. If your access reviews, change approvals and vulnerability scans began recently, a Type 2 date is not credible yet. Inventory what evidence exists today, how often each control runs and who owns it. Commit to a Type 1 date only when the controls already run and the first Type 2 window can start from a known point.

The customer's regulator

A bank's regulator shapes the interim answer more than the buyer's preferences do. US banking agencies say a bank may consider SOC reports and independent certifications during due diligence, and a proposed guide for community banks lists penetration testing reports among independent assessments a bank may rely on. Ask the buyer which regulator examines them and whether their third-party policy names specific assessments. European customers under DORA or NIS2 may need different evidence, including audit rights that a report does not replace. The regulator sets the minimum; the contract sets the rest.

Who owns what while you wait for the report

Your organization owns every control it describes to a customer, and it carries the consequences if a control does not operate as written. No outside party can accept that ownership for you. While you wait for a report, your team decides which controls to commit to, approves the policies that describe them, and signs off on the system description that the auditor will test. Your team also decides whether to commit to a Type 1 date at all.

Control ownership: Named individuals run each control day to day, such as access reviews, change approvals and incident response.
Policy approval: Leadership approves the security policies and records that approval with a date and version.
System description: Your team confirms the services, infrastructure and subservice organizations in scope before any examination starts.
Commitment decisions: Leadership decides whether a Type 1 date is achievable and what happens if the date slips.
Customer communication: Your team writes what the customer is told about status, so no statement overstates the controls in place.

Before you send anything to a customer, check that each claim maps to a control your team already runs and can show evidence for.

Questions buyers ask before the report exists

Can we send a penetration test report instead of a SOC 2?

Yes, as interim evidence, but it does not stand in for a SOC 2 report. A penetration test shows how a defined scope of systems held up to testing on the dates it was run, and it says nothing about whether your controls were designed suitably or operated over time. US banking guidance treats penetration testing reports as one kind of independent assessment a bank may rely on, alongside SOC reports and industry assessments, so a bank may accept it as one input to due diligence. Send the full report with its scope, dates and tester identity, and expect follow-up questions on any findings that remain open. Remediation records for those findings are what make the report useful. Testing itself is usually scoped and priced by the testing firm from the systems in scope, so ask for the scope in writing before you commit.

How long does a SOC 2 Type 1 take to plan?

The planning period depends mostly on how ready your controls already are, not on the audit itself. A Type 1 report describes your system and the suitability of control design as of a specific date, so the work before that date is writing the system description, mapping controls to the criteria, and getting policies approved and in use. Teams that already have access reviews, change records and an asset inventory usually spend less time than teams building those records from scratch. Ask any auditor or partner for a written timeline that lists the readiness assessment, control implementation, the agreed as-of date and the report delivery, and check which of those steps depend on your own staff being available.

What does a SOC 2 cost us in staff time?

Staff time is usually the larger cost, and it recurs in ways the audit fee does not. Expect ongoing effort from an executive sponsor, the engineer who owns infrastructure and access, someone to collect evidence, and whoever handles HR onboarding and offboarding records. Published estimates from the Justice Department's 2024 proposed rule put SOC 2 audit fees at $5,000 to $25,000 for a Type 1 and $30,000 to $100,000 for a Type 2, which are external costs only and exclude internal labor. To estimate internal time, list each control, the person who performs it, and how often the evidence must be produced, then ask your auditor to confirm which evidence they will sample.

Can a partner issue the SOC 2 report for us?

No. Only an independent CPA firm can examine your controls and issue a SOC 2 report. An implementation partner can help plan the examination, prepare systems, configure logging and access controls, and organize evidence, but the organization owns its controls and management signs the assertion and representation letter. DeployOpen prepares systems, controls and evidence for compliance assessments; it does not issue audit reports, attestations or certifications. Ask the CPA firm whether it has any independence concerns with a preparation partner before engagement starts, and confirm in writing who does which task.

Will a STAR Level 1 self-assessment satisfy a bank?

It may help, but a STAR Level 1 self-assessment is not an independent examination, so it is unlikely to satisfy a bank on its own. The Cloud Security Alliance lists STAR Level 1 as a free self-assessment in which you complete the CAIQ v4 questionnaire and publish it in the public STAR Registry, updated annually. CSA positions the registry as a way to reduce repeated customer questionnaires. Banks, however, look for independent assessment reports during third-party due diligence, and the US interagency guidance allows them to review SOC reports and independent certifications. Present the STAR entry as a standard answer set that shows your posture, and pair it with a dated penetration test and a clear plan for the SOC 2 examination.

What happens if the auditor finds gaps?

The auditor records what they find, and the outcome depends on whether the gap is an exception in the report or a control that must be fixed before the examination starts. Exceptions are documented in the report, and a report with exceptions is still a report, but buyers read exceptions closely. Gaps found during readiness are better handled before the as-of date, because fixing a control after the date does not change the earlier result. Ask your CPA firm to walk through likely exceptions during readiness, agree on remediation evidence in writing, and explain how gaps are reported in the final opinion so that you can answer buyer questions accurately.

Should we start a Type 2 observation period now?

Start the Type 2 period only once the controls are designed and running consistently, because the report tests operating effectiveness over a period. The 2011 Journal of Accountancy article notes there is no generally accepted minimum period for a Type 2, so the length is agreed with the auditor based on what the examination must cover and what users need. A Type 2 started before controls are stable tends to record exceptions that a Type 1 would have hidden. Many organizations use a Type 1 first to prove design and then move to a Type 2. Ask your auditor which period they recommend for your first report and what evidence they will sample across it.

Where a fixed-scope engagement fits

If a deal needs SOC 2 and no report exists yet, the first question is often whether outside help should cover some of the work between now and an examination. DeployOpen engagements are typically fixed-scope: the scope, deliverables and timelines are agreed in writing before any work starts. For this situation, that scope might cover preparing the systems and evidence an auditor will request, documenting controls, or running security testing that produces a penetration test report a buyer can review. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask any provider, including DeployOpen, to state in writing what is included, what the customer must supply, and what is excluded.

Be clear about roles when you write that scope. The organization owns its controls and its management assertion. An implementation partner prepares systems, configurations and evidence. Only an independent CPA firm can perform the examination and issue a SOC 2 report. A scope that promises a report, a certification or a specific audit result is describing a role the partner does not hold. Confirm with the CPA firm early whether it will accept the prepared evidence and what period it will test, because those answers shape how much preparation is actually needed.

Security testing and ongoing retainers are available as separate engagements. A penetration test can be scoped on its own to give a buyer an independent test report while the examination is pending. A retainer can cover continued support, upgrades and testing once the first report exists, which matters if a Type 2 observation period is planned. Ask for these as distinct line items in the quote so you can see what is one-time and what recurs, and so you can decide which parts to start now.

How DeployOpen prepares your controls and evidence for the examination

When a deal needs SOC 2 and no report exists yet, DeployOpen helps you prepare the systems, controls and evidence an independent CPA firm will test. We do not issue reports, and the scope, deliverables and timeline are agreed in writing before work begins.

How we scope

We agree in writing which Trust Services Criteria, systems and services fall within your SOC 2 scope before any work starts.
We map the customer's stated needs to the controls you can credibly operate by the date you commit to, so the scope matches what you can prove.
We identify which controls your cloud provider or other subservice organizations cover, so you know what to ask them for.

How we build

We configure self-hosted open-source platforms inside your own cloud accounts or data centers to run access, logging, change and backup controls.
We write the control descriptions and a control matrix that show how each control is designed, owned and performed.
We test the controls ourselves and fix gaps before the CPA firm arrives, so the first examination starts from a documented baseline.

How we hand over

We deliver the system description, control matrix, policies and evidence library in formats your auditor can sample from.
We document ownership, recurring review tasks and evidence locations so your team can keep producing evidence after handover.
We leave the assertion, representation letter and report decisions with your management and the independent auditor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which can carry the controls into an observation period.
We can prepare responses to auditor evidence requests and walk your team through the evidence behind each control.
We can help you prepare bridge documentation and updates to the system description when the platform or scope changes.