Got Asked for SOC 2 by a US Customer? Here's Your 90-Day Playbook

The email landed on a Tuesday. “Before we move forward, our security team will need your SOC 2 Type II report.” The deal you’ve been working for six weeks just hit a wall — and you don’t have a SOC 2. This is the most common, deal-velocity-affecting compliance trigger Indian SaaS founders face, and the playbook below is the same one we walk founders through on emergency triage calls. The aim is to keep the deal alive, buy time honestly, and stand up enough compliance posture in 90 days to clear procurement.

Read this top-to-bottom if your customer just asked. Skip to the Day-1 buy-time email template if you only have 30 minutes before your reply is overdue.

What the customer is actually asking for (and what they’ll accept)

When a US enterprise security team writes “we need your SOC 2 Type II”, they are usually communicating one of three things:

1. Hard requirement. SOC 2 Type II is a procurement gate. No report, no vendor onboarding. The decision-maker has no flexibility.
2. Soft requirement. SOC 2 Type II is the default but the security team will accept a credible alternative — a SOC 2 Type I, an ISO 27001 certificate, or a documented in-flight programme — for a defined bridging period.
3. Misnomer. The customer’s procurement system has “SOC 2 Type II” hard-coded into the vendor questionnaire but the security team is willing to accept any independent third-party assurance — sometimes even a recent CERT-In empanelled VAPT report and a security overview.

You don’t know which one until you ask. Do not respond by saying “we don’t have one” and hoping for the best. Respond by asking a specific question that surfaces which of the three categories applies.

Day 1 — the buy-time email template

The single most important action on Day 1 is to send the right reply. The wrong reply (“we’ll get one”) loses the deal because it doesn’t surface the customer’s flexibility. The right reply asks two questions and signals seriousness.

Subject: Re: Security review — vendor onboarding

Hi [Name],

Thanks for surfacing the SOC 2 requirement before procurement — it lets us scope the right path forward.

So we can give you the most useful response, two quick questions:

1. Is SOC 2 Type II a hard procurement gate, or would your security team accept a documented in-flight SOC 2 programme with a target attestation date, supported by an independent third-party assurance report (ISO 27001 / CERT-In empanelled VAPT) for the bridging period?

2. If Type II is required, would your team accept SOC 2 Type I as the initial deliverable while the Type II observation window completes?

Background on our posture: we operate a partner-led security practice with India-resident audit data, an active vulnerability management programme, [your specific posture detail — IAM/MFA, encryption, monitoring]. We can share our security overview deck and a current VAPT summary under NDA on a 24-hour turnaround.

Happy to set up a 30-minute call this week to walk you through how the platform handles the bridging-assurance evidence package. Otherwise, let me know which of the two paths above your team can support and we’ll come back with a credible plan and timeline.

Best, [Your name]

Three things this email does:

• Surfaces the customer’s flexibility by making them tell you whether Type II is hard or soft.
• Signals seriousness by mentioning specific posture detail and offering an NDA-bound security overview.
• Buys time by proposing a 30-minute scoping call rather than a yes/no answer.

In 70%+ of cases, the customer’s reply will reveal the requirement is softer than the original ask suggested.

Days 2–7 — what to build this week

Whichever category the customer is in, the following are non-negotiable to build by end of Week 1:

• A two-page security overview deck. Cover: company info, hosting infrastructure (cloud provider, region), data-handling overview, encryption-at-rest and in-transit posture, MFA status, backup and DR posture, current vulnerability management cycle, named security contact. Brand it cleanly. Send it under NDA.
• A current VAPT summary. If you have one, redact and share. If you don’t, scope a CERT-In empanelled VAPT engagement immediately — ideally one that delivers a draft report within 4 weeks. See our VAPT cost factors guide for engagement scoping.
• A vendor security questionnaire response. Most enterprise customers will send their version of CAIQ, SIG-Lite, or a custom questionnaire. Answer every question concretely; “Not applicable” is acceptable, “Will implement” is acceptable, “Refusing to answer” is not.
• An incident response contact and runbook. The customer’s security team will ask. Have a single named contact, an escalation chain, and a documented response workflow — even if it’s one page. See our incident response playbook for structure.

The combined 5-day deliverable is achievable for any Indian SaaS company with reasonable engineering discipline. The artefacts buy 4–8 weeks of breathing room while you stand up the formal SOC 2 programme.

Days 8–30 — start the SOC 2 programme

By Day 30, you need to be in a defensible position with the customer. The actions that matter:

Week 2 — Choose the framework path

The decision tree:

• If the customer accepts ISO 27001 as bridging assurance and you are India-targeting + APAC-exposed, start ISO 27001:2022 in parallel with SOC 2. ISO certification often arrives first (12–14 weeks) and clears the procurement gate while SOC 2 Type II’s observation window completes. See our ISO 27001 vs SOC 2 decision tree.
• If the customer requires SOC 2 specifically, start with SOC 2 Type I (point-in-time attestation, ~8 weeks) followed by Type II (operating-effectiveness attestation, requires 6+ month observation). Type I issued in Week 8–10 frequently clears the procurement gate as bridging assurance.
• If the customer requires SOC 2 Type II strictly, you are in a 6–9 month timeline. Negotiate a written commitment-to-vendor-onboarding-on-Type-II-issuance from the customer; in return you commit to a specific observation-window-start date. This converts the “no SOC 2” objection into a “SOC 2 in flight” approval.

Week 3 — Engage the consultant and auditor

By end of Week 3 you should have:

• A signed scoping document with a SOC 2 readiness consultant. The consultant’s job is to surface gaps, author policies, and prepare evidence collection. See our SOC 2 service page and the six factors that drive SOC 2 cost for engagement scoping.
• A shortlist of 3 audit firms (CPA-licensed, AICPA peer-reviewed) with quotes in hand. The auditor and the consultant should be different firms — auditor independence is a SOC 2 prerequisite.
• A target observation-window-start date, communicated to the customer in writing.

Week 4 — Open the readiness work

By end of Week 4:

• Information security policy in draft.
• Access-control matrix mapped (who has access to what production systems).
• Vendor inventory with sub-processor list.
• Vulnerability management cadence committed (monthly scans, quarterly VAPT, see VAPT cost factors).
• Incident response runbook in draft.
• Background-check workflow documented for new hires.
• MFA enforced across all production-access tooling (if not already).
• Centralised logging configured to a write-only destination with object-lock retention.

This is approximately 60% of the readiness scope. The remaining 40% involves evidence collection over the observation window, which begins formally once readiness is signed off.

Days 31–60 — readiness completion and observation window prep

The second month is about closing readiness gaps and preparing to open the formal observation window. The customer-facing communication continues weekly.

Customer cadence

• Day 30 weekly status email to the customer’s security team: programme is on track, target observation-window-start date confirmed, key milestones for the upcoming week.
• Day 45 mid-point update: policies finalised, gap assessment complete, evidence collection beginning, target Type I attestation date confirmed.
• Day 60 Type-I-readiness confirmation: policies and controls operating, ready for Type I fieldwork.

Internal milestones

By Day 60 the readiness baseline should include:

• All AICPA Trust Services Criteria controls mapped to your environment.
• Access reviews completed for the most-recent quarter, with documented evidence.
• Quarterly tabletop exercise completed and documented.
• VAPT report available, with remediation tracked.
• Vendor risk reviews completed for top-10 sub-processors.
• DR/BCP testing completed and documented.
• Customer-facing security overview updated with concrete posture rather than aspirational language.

The Day 60 baseline is what an auditor inspects during Type I fieldwork. If you arrive at Day 60 with these deliverables in hand, Type I attestation is straightforward.

Days 61–90 — Type I fieldwork and procurement clearance

The third month executes Type I fieldwork and uses the issued attestation to clear procurement.

Type I fieldwork (Days 61–80)

The auditor’s fieldwork typically takes 2–3 weeks for a first-time SOC 2 engagement at modest scope. Activities include:

• Walkthrough sessions with key control owners (engineering lead, security lead, IT operations).
• Sample-based evidence testing across the in-scope controls.
• Management representation letter signed.
• Auditor’s report drafted, internal review completed, partner sign-off.

The Type I report typically issues within 2 weeks of fieldwork completion.

Procurement clearance (Days 80–90)

With the Type I report in hand:

• Send under NDA to the customer’s security team.
• Confirm vendor-onboarding can proceed with Type I as bridging assurance and Type II to follow on the agreed timeline.
• Update the customer’s security questionnaire with concrete posture references and the Type I report.
• Get written confirmation that vendor-onboarding proceeds.

In our experience, ~85% of customers who initially asked for Type II accept Type I + committed Type II timeline as bridging assurance, especially when supported by a credible 90-day execution narrative.

What this costs and what it prevents

The 90-day playbook is genuinely intensive. The costs:

• Consultant engagement for readiness and gap closure.
• Auditor engagement for Type I and (subsequently) Type II.
• VAPT engagement for vulnerability management evidence.
• Internal engineering effort: typically 15–25% of one engineer’s time during the readiness phase.
• Optional GRC tooling (Vanta, Drata, Sprinto, Scrut) for evidence automation.

What it prevents:

• The deal in question slipping or being lost entirely.
• Subsequent enterprise deals being lost for the same reason.
• A reactive, over-priced, panic-driven engagement on Day 60.
• A loss of credibility with the customer’s security team.

For a Bangalore SaaS company with $X ACV enterprise deals in pipeline, the math is rarely close: the 90-day investment pays back inside the first 1–2 deals it unblocks.

Common 90-day playbook mistakes

1. Saying “we’ll get one” without a timeline. The customer hears “we don’t take this seriously”. Always commit to specific dates.
2. Skipping Day 1’s buy-time email. Founders sometimes panic-promise SOC 2 Type II by a date they cannot hit. Better to surface the customer’s flexibility first.
3. Engaging a US-only auditor without India presence. Time-zone friction and regulator-context gap slow the programme materially. Indian-CPA firms with US licensure typically deliver faster — see our SOC 2 cost factors guide for auditor selection.
4. Skipping readiness assessment. Going straight to fieldwork without gap closure produces qualified opinions. Plan for 2–3 weeks of readiness before Type I.
5. Defaulting to Type II strict timeline without negotiating bridging. Most customers accept Type I + committed Type II; negotiating this saves 6 months of pipeline pain.
6. Skipping VAPT. Auditors expect vulnerability management evidence. A concurrent VAPT engagement in Days 1–30 produces the evidence by Day 30.
7. Not communicating weekly. The customer’s security team interprets silence as inaction. Weekly updates with concrete progress preserve credibility.
8. Hiring a full-time security person under panic. A vCISO retainer (see hiring triggers) at this stage typically delivers more value than a junior full-time hire.
9. Treating SOC 2 as one-deal infrastructure. SOC 2 is annual programme infrastructure. Build for the annual cycle, not the immediate deal.
10. Underestimating evidence discipline. SOC 2 is 80% evidence collection. Build the discipline from Day 1 of readiness.

When the 90-day playbook is genuinely insufficient

Three scenarios where the 90-day plan is not enough:

• The customer is a Big-4 audit client whose auditor has dictated specific Type II report requirements. These engagements may require Big-4-tier auditor pedigree and 12-month observation windows.
• The customer is a regulated financial-services enterprise (Tier 1 US bank). Their security team often requires SOC 2 + ISO 27001 + specific penetration testing + multi-year track record.
• The customer’s procurement is closing a fiscal quarter and won’t extend beyond 30 days. No 90-day playbook saves this deal; the realistic action is to commit to vendor-onboarding for the next purchase cycle.

In these cases the playbook still applies but the deal-rescue framing changes. We discuss these cases on triage calls.

How to know if you should run this playbook yourself or engage help

The signals that you should run the 90-day playbook with internal resources only:

• Engineering team has 1+ senior with prior compliance exposure.
• Existing infrastructure-as-code, centralised logging, MFA enforcement, basic access-management discipline.
• Founder/CTO has bandwidth for ~10 hours/week of compliance ownership for 90 days.
• One known target deal is the trigger; broader compliance demand is not yet present.

The signals that you should engage external help:

• This is the second or third enterprise prospect requesting SOC 2 in the last 90 days.
• The internal team has no prior compliance exposure.
• Engineering is at full capacity on product roadmap; compliance ownership cannot be carved out.
• The deal value justifies external execution speed (typical break-even point: deals worth substantially more than the 90-day engagement cost).

For organisations in the second category, the platform compresses the 90-day playbook to 60–75 days because the platform carries the policy authoring, evidence-collection workflow, and auditor-portal handoff — your team focuses on the customer relationship and remediation calls.

Practical next steps

If you want a 30-minute triage call to map your specific customer’s flexibility and your specific 90-day plan, the contact form in the site footer books the call directly. If you want to understand the cost factors before committing, see our SOC 2 cost factors guide and VAPT cost factors guide. If you want to explore whether ISO 27001 is the right bridging assurance for your customer, see our ISO 27001 vs SOC 2 decision tree.

For the deal in front of you, the single most important action is to send the Day-1 buy-time email before the customer interprets your silence as a no.

90-day playbook FAQ

My customer’s email arrived yesterday — should I send the buy-time email even though I’m late? Yes, and acknowledge the delay in your reply. Late-but-thorough beats fast-but-vague.

My customer rejected SOC 2 Type I as bridging — what now? This is rare but happens. The realistic options: (a) negotiate a longer onboarding window aligned with Type II issuance; (b) propose ISO 27001 as bridging if they have global presence; (c) accept the deal will close on Type II issuance and focus on keeping the prospect engaged through monthly cadence calls.

Can I use a SOC 2 report from one of our subprocessors? No. SOC 2 reports cover a specific organisation’s controls. Your subprocessors’ reports are useful as evidence of their controls but do not substitute for your own attestation.

Should I tell the customer about specific compliance gaps? Selectively. Major gaps that affect the customer’s risk should be disclosed (e.g., no MFA enforcement, no encryption-at-rest). Minor gaps are best held until they are remediated and can be presented as completed posture.

Is SOC 2 Type I a “real” SOC 2? Yes. Type I is design-effectiveness attestation at a point in time. Type II adds operating-effectiveness attestation over an observation window. Both are issued by AICPA-licensed CPA firms and are real SOC 2 attestation reports.

My customer is in Europe — do they really want SOC 2? Sometimes. Many European enterprises accept ISO 27001 as primary assurance with SOC 2 as supplementary. Confirm specifically; do not assume the request is non-negotiable.

Should I build internally or use a GRC platform like Vanta or Drata? GRC platforms automate evidence collection but cost annual subscription. For first-time SOC 2 with a 90-day deal-rescue trigger, the GRC platform shortens implementation by 2–4 weeks. After Year 1, the platform becomes optional infrastructure.

Can I run SOC 2 and ISO 27001 in parallel? Yes, and we recommend it for organisations with mixed US/EU pipelines. The combined programme typically costs 1.3× the SOC 2 fee alone rather than 2× because the control overlap is roughly 60%.

My customer asked specifically for SOC 2 with all five Trust Services Criteria — is that normal? No. Most SOC 2 engagements scope to Security only; some add Availability or Confidentiality. Five-TSC reports are rare and meaningfully more expensive. Confirm with the customer’s security team whether they need all five or whether their default questionnaire mentions all five but Security-only is acceptable.

Will my SOC 2 expire? Yes, annually. Each annual renewal requires a fresh observation window and Type II report. Budget for the annual cycle, not just Year 1.

What if my customer wants HITRUST or HIPAA compliance instead? HITRUST and HIPAA are healthcare-specific. If your customer is a healthcare entity, scope to HITRUST + HIPAA mapping rather than vanilla SOC 2. The methodology is similar but the report structure differs.

Can I share my SOC 2 report publicly? No. SOC 2 reports are typically shared only under NDA. SOC 3 reports (less detailed) are publicly shareable but rarely sufficient for enterprise procurement.

My customer is a Series-C startup, not a Fortune 500 — does the same playbook apply? Yes, with one variation: Series-C startups sometimes accept self-attested security overviews + VAPT reports + DPA signing without formal SOC 2. Probe the flexibility before committing to the full SOC 2 programme.

The customer wants a security questionnaire response by Friday but it’s Wednesday — what do I do? Two days is enough for a first-pass response. Use the questionnaire to surface specific concerns; questions you cannot answer become Day-1 priorities. Commit to a comprehensive update by Day 14.

My internal team has zero compliance exposure — is 90 days realistic? With a partner-led consultant carrying the readiness work, yes. Without external help and with engineering already at capacity, 90 days is aggressive. Plan for 120–150 days and communicate that timeline transparently.

Why we built this playbook

We see this scenario every week. A Bangalore SaaS founder gets the SOC 2 email, panics for 48 hours, then makes one of three errors: promises a date they cannot hit, hires a Big-4 firm at 5× cost under emergency timing pressure, or replies with “we don’t have one” and watches the deal die. None of those is necessary. The 90-day playbook compresses the deal-rescue path into a structured, communicable, executable sequence — and the founders who execute it cleanly typically close the original deal and convert the SOC 2 programme into a compounding revenue lever for the subsequent 18 months.

If you are currently mid-deal and reading this, send the Day-1 email before the end of business today. Everything else can be scheduled.