Your US customer sent a security questionnaire to your Indian startup. Here's what they're actually checking

The first enterprise deal is going well until procurement forwards a spreadsheet. Two hundred rows, written by a security team in San Francisco or New York, assuming a vendor in the same country. You are in Bengaluru or Pune, your compliance posture is shaped by Indian law, and roughly a third of the questions do not obviously apply to you.

They still have to be answered, and answered in the buyer's frame rather than yours. Here is how the two worlds line up.

What the buyer is actually asking

Almost every enterprise vendor security questionnaire is a restatement of the same handful of concerns. Strip the phrasing and you get:

• Can someone impersonate you? — email authentication (DMARC, SPF, DKIM), domain hygiene, certificate posture.
• Is data protected in transit and at rest? — HTTPS everywhere, HSTS, encryption on your databases and object storage.
• Who can reach production? — MFA on every admin, SSO, offboarding that actually removes access.
• Do you know what you're running? — dependency and container vulnerability management, a patching cadence you can describe.
• Has anyone independent tested it? — a penetration test report, dated within the last twelve months.
• What happens when something goes wrong? — an incident response plan, a breach notification commitment, and a named human.

None of that is US-specific. It is the same list whether you are in Austin or Ahmedabad — which is the good news, because it means the work is portable across every deal you will ever do.

Which Indian regulations the buyer cares about

This is where Indian vendors lose time, usually by volunteering the wrong things. A US enterprise buyer's security team is trying to answer one question: if we hand you our customers' data, what is the risk to us? Indian regulation matters to them only where it changes that answer.

• CERT-In Directions (2022) — matters, and it is worth raising yourself. It obliges you to report certain classes of incident to the Indian authorities within six hours of noticing them. A buyer reads a mandatory six-hour clock as a stronger commitment than most vendors offer voluntarily. Say so.
• The DPDP Act 2023 — matters if you process personal data of people in India. It is India's general data-protection law and it is the closest analogue to the GDPR framing most enterprise questionnaires are built around, so it is the right thing to cite when a row asks about your privacy regime.
• RBI Cyber Security Framework — matters only if you sell to, or process data for, Indian regulated financial entities. If your buyer is a US software company, it is noise.
• SEBI CSCRF — same: relevant for Indian securities-market entities, irrelevant to a US buyer's risk model.

The mistake is to answer a US questionnaire with a wall of Indian regulatory detail, which reads as evasion. Answer the question they asked, then note the Indian obligation where it strengthens your position — CERT-In's reporting clock genuinely does.

What they will ask for that Indian law does not give you

There is no Indian equivalent of SOC 2, and this is the single most common stall. SOC 2 is not a law and not a government scheme. It is an attestation performed by a licensed accounting firm against the AICPA's Trust Services Criteria, and a US enterprise buyer will very often treat it as the default proof of a functioning security programme.

Two practical consequences. First, no amount of Indian compliance substitutes for it in the buyer's mind — you cannot answer "are you SOC 2?" with "we comply with DPDP". Second, you do not need the audit to unblock the deal today. What unblocks most deals is evidence that the underlying controls exist and are working, plus a credible date for the audit. Buyers accept that far more often than founders expect, because their actual fear is an unmanaged vendor, not a missing PDF.

ISO 27001 is the other common answer, and it travels better internationally than SOC 2 does. If you are selling into both the US and Europe, it is usually the more efficient first certification.

The order that saves the most time

Do the externally-visible work first. Before anyone reads a policy document, the buyer's security team — or their automated vendor-risk tool — will check what they can see from outside: your email authentication, your TLS configuration, your security headers, whether you publish a security contact. Those checks are cheap for them to run and they set the tone for everything that follows. Failing them means starting the conversation on the back foot for reasons that take an afternoon to fix.

Then close the internal gaps that map to the six concerns above. Then start the audit, if the deal size justifies it. Running that order in reverse — starting with the audit and discovering your DMARC record was missing the whole time — is how a quarter disappears.

One artifact, reused

The reason this work compounds is that the second questionnaire is mostly the first questionnaire. The controls do not change per buyer; only the phrasing does. If you keep the evidence in a form you can hand over — findings with the tool that proved them, mapped to the control each one affects — then every subsequent review is a lookup rather than a project.

That is the whole argument for treating the first security review as infrastructure rather than as a fire. You are going to be asked these questions by every enterprise customer you ever sell to.