TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →Imagine the last week of the quarter. Your sales team has a large customer ready to sign, and the contract is in legal review. Then an email arrives from the customer's security team: a spreadsheet with a few hundred questions about how you protect their data, and a request for your latest penetration test report. Nobody on the sales side knows the answers, and the deal now waits on them.
This happens because buyers have learned what a vendor's weakness costs them. Verizon's 2026 Data Breach Investigations Report, as reported by Expert Insights, found that 48% of breaches involved a third party, up from 30% a year earlier. Nearly half of breaches now involve someone else's systems, so buyers check first. A SaaS security assessment, done by you before the buyer does theirs, is how you find out whether your answers will hold up.
Why Buyers Look Harder Than They Used To?
A SaaS product usually holds the buyer's data, connects to the buyer's systems, or both. When it fails, the buyer has the incident. The Drift and Salesloft token theft of August 2025, which Google's threat intelligence group said potentially affected over 700 organisations, was an integration problem for customers who had done nothing wrong themselves.
For Indian buyers there is a legal side. Section 8(1) of the DPDP Act keeps a Data Fiduciary responsible for compliance even when a Data Processor handles the data, "irrespective of any agreement to the contrary." The main DPDP duties are due to apply from about mid-May 2027. A buyer cannot pass that responsibility to you, so it will want evidence that you are reducing its risk.
What the Review Usually Looks Like?
Expect two things: a questionnaire and a document request.
Questionnaires.
The spreadsheet in the opening is usually a standard format, so many buyers send the same one. The Cloud Security Alliance's CAIQ is a set of 261 yes-or-no questions (version 4) about the controls a cloud service has in place, and CSA notes it is a self-assessment, not a certification. According to a comparison published by Agency, the SIG, from the Shared Assessments consortium, is typically used by financial services, healthcare, and insurance buyers and has a Lite version of about 200 questions, while the Vendor Security Alliance format, at roughly 100 to 150 questions, is common among technology companies. Those counts are approximate and secondary-sourced.
Documents.
A guide from ComplyDog lists the items buyers commonly ask for: a SOC 2 report, an ISO 27001 certificate with its scope and Statement of Applicability, a recent penetration test report, a data processing agreement, a subprocessor list, a cyber insurance certificate, security policies, an architecture or data flow diagram, and a business continuity and disaster recovery plan. This is one practitioner's list, not a standard.
Seven Things Enterprise Buyers Expect to See
1. Independent assurance, read correctly.
Buyers usually want a SOC 2 Type II, which covers controls operating over a period, not just their design at one date. If you hold only a Type I, say so plainly. For ISO 27001, the scope statement matters more than the certificate itself.
2. Recent, scoped penetration testing.
A test within the last twelve months, covering the production application, APIs, and cloud setup, with severity counts, remediation status, and a retest. ComplyDog's view is that a summary with several high-severity findings plus a remediation letter reads better than a report showing none, which suggests a narrow scope. Either way, a clean report on a thin scope will not help you.
3. Tenant isolation and access control.
Buyers want to know how one customer is kept from another's data, how privileged access is controlled, and whether multi-factor authentication covers staff, admins, and support tooling.
4. Data protection and subprocessors.
Where data lives, how it is encrypted, who else touches it, and how you notify customers of subprocessor changes.
5. Incident response and notification terms.
A tested plan, named owners, and a commitment on how quickly customers will hear from you. Buyers subject to CERT-In's six-hour reporting rule for serious incidents will push for timelines they can live with.
6. Resilience.
Recovery objectives, the date of your last restore test, and single points of failure.
7. Governance of AI features.
If your product uses models or agents, expect questions about which models, what data is sent to them, how prompt injection and data leakage are tested, and what the assistant can do on a customer's behalf. This is a growing category, and most vendors have thinner answers here than elsewhere.
Where Assessments Go Wrong?
* The scope does not match the product.
One practitioner's analysis of SOC 2 (published on zeltser.com) notes that the audited company defines the system boundary and selects the auditor, so a SOC 2 report may not cover the systems a buyer relies on. Its advice to buyers is to ask which systems and processes were excluded.
* Evidence is out of date.
A report from two years ago, a pen test that predates your last major release, or a policy that nobody follows will each raise more questions than they answer.
* Answers come from memory.
"Yes, we encrypt data at rest" is not evidence. A configuration export, a screenshot, or a log is.
* The controls exist on paper.
The same piece warns that controls might exist during an audit and lapse once the report is issued. A buyer who asks for sample evidence from the last quarter is testing for exactly that.
Running Your Own SaaS Security Assessment
Before the buyer asks, we would work through five steps.
1. Map the buyer's questions to your evidence. Take CAIQ or your most common questionnaire and mark each answer as proven, claimed, or unknown.
2. Test the product like an attacker. Cover the web application, APIs, tenant boundaries, and any AI features, through VAPT in line with your deployment pattern.
3. Check scope against what buyers rely on. If a certification excludes a system customers depend on, either extend the scope or prepare a clear explanation.
4. Close the cheap gaps first. Typically MFA coverage, logging retention, a tested restore, and a current subprocessor list.
5. Package the evidence once. A trust pack with the report, a pen test summary, policies, and a data flow diagram, with a named owner and a review date, saves weeks per deal.
Where ILLUME Intelligence Can Help
ILLUME Intelligence helps SaaS companies prepare for enterprise review. Our Penetration Testing and AI Penetration Testing (AI VAPT) services produce buyer-ready test evidence, our SOC 2 and ISO 27001 services support independent assurance, our DPDP compliance service aligns your data handling and processor terms, and our vCISO service can own the programme. A gap review against one real buyer questionnaire is a practical first step.
The Bottom Line
Enterprise buyers are not asking whether you take security seriously. They are asking you to prove it, in a format their reviewers can check.
Test your product, close the gaps, match your evidence to your scope, and keep it current, so the next questionnaire is a retrieval exercise and not a scramble.
