Why AI Vendor Risk Assessments Still Get It Wrong — and How to Fix Them Under DPDPA
AI promised to turn weeks of vendor questionnaire review into minutes. In practice, most AI risk-scoring tools produce results that are technically defensible and practically useless. Here is why, and what a DPDPA-aware fix actually looks like.
DataDefend Editorial Team
Privacy & Compliance Experts
June 23, 2026 ◦ 10 min read
Table of Contents
The Promise Was Simple. The Reality Is Not.
Vendor risk assessment sounds like an obviously good fit for AI: feed in a vendor's SOC 2 report, security questionnaire, and policy documents, and get back a risk score in minutes instead of the days a manual review would take. Several teams have tried to build exactly this. Most discover the same set of problems in roughly the same order.
Under the DPDP Act, the stakes for getting vendor risk wrong are not abstract — Data Fiduciaries remain accountable for how their Data Processors and other vendors handle personal data, regardless of who actually mishandled it. A risk-scoring tool that produces unreliable output does not just waste time; it creates a false sense of assurance over exactly the relationship most likely to cause a breach.
Challenge One: Vendors Don't Send Clean Data
Real vendor submissions are not tidy. A single vendor pack might include a 90-page SOC 2 report, a sales deck, a scanned and slightly rotated ISO certificate, and a security FAQ pasted into an email. Extracting the right content from this mix — while deciding what to keep within a limited context window — is harder than it sounds.
Cut the wrong section, and the system can miss a genuine control gap entirely while reporting high confidence in its output. This is the first place naive AI vendor risk tools fail silently: not by crashing, but by quietly dropping the one paragraph that mattered.
Challenge Two: The Same Gap Means Different Things to Different Vendors
This is the hardest problem to solve, and the one most teams underestimate. A missing multi-factor authentication control is a minor note for a vendor that never touches personal data. For a Data Processor handling sensitive personal data — health records, financial data, biometric identifiers — the same gap is a material risk that could expose you to DPDPA liability if that vendor is breached.
- What category of personal data does this vendor actually access, and is any of it sensitive personal data?
- Is the vendor acting as a Data Processor under Section 8, or simply providing infrastructure with no data access?
- Does the vendor sub-process data to further third parties, and is that visible at all?
- Does the vendor's infrastructure involve any cross-border transfer of data categories India restricts?
An AI system that scores every vendor against the same generic checklist, blind to these distinctions, produces results that look rigorous but are practically useless for deciding where to actually focus.
Challenge Three: Flagging Everything Is the Same as Flagging Nothing
The early version of most AI risk tools errs toward caution and flags every possible gap, every vague clause, every missing detail. The result is a report so long that the genuinely material risks drown in noise, and compliance teams stop trusting the output within a few weeks.
"The fix rarely comes from a better model. It comes from a structured framework that distinguishes material risk, documentation gaps, and stylistic concerns — and that framework has to be built by people who understand the compliance standard, not just the language model."
The Blind Spot Generic Tools Have: DPDPA Itself
Even AI vendor risk tools that handle the three challenges above reasonably well typically still have no concept of DPDPA-specific obligations baked in. They were trained and tuned against SOC 2 and ISO 27001 control language, not against Section 8 processor obligations, data localisation requirements, or breach notification clauses specific to Indian law.
Practically, this means a generic tool can correctly tell you a vendor has weak encryption practices, but cannot tell you whether that vendor's data flows trigger a localisation requirement, or whether their sub-processor arrangement needs to be reflected in your own data processing agreement under Indian law.
The Problem Nobody Talks About: Vendor Risk Doesn't Freeze
Most vendor risk programmes — AI-assisted or not — treat the assessment as a one-time gate at onboarding. But certifications expire, sub-processors change, and a vendor's risk profile shifts the moment they add a new product feature that touches more personal data than before.
Few programmes have automated tracking for expiring SOC 2 reports, lapsed ISO certifications, or stale assessments that quietly age past their useful life — leaving security teams to discover the gap only when something goes wrong, or when an auditor asks for the latest evidence and there isn't any.
What a DPDPA-Aware Fix Looks Like
- Map every vendor response to a specific control framework, including DPDPA-specific clauses, instead of a generic checklist
- Tier severity by the vendor's actual data access and processor classification, not a uniform score across all vendors
- Build a structured distinction between material risk, documentation gap, and stylistic concern before scaling flagging volume
- Route ambiguous or high-stakes flags to human review rather than auto-resolving them silently
- Automate reassessment scheduling tied to certification expiry dates and material changes in the vendor relationship
Domain expertise — someone who actually understands what a DPDPA control gap means in practice — is not optional infrastructure here. It is the difference between a risk score that is defensible on paper and one a compliance team can actually act on.
Built to Score Risk the Way DPDPA Actually Measures It
DataDefend's vendor risk module was built around this exact set of problems — mapping vendor responses to DPDPA-specific obligations, tiering severity by data sensitivity and processor classification, and automating reassessment as certifications age, instead of treating vendor risk as a one-time checkbox.
If your current vendor risk process — AI-assisted or manual — is producing reports nobody trusts enough to act on, see how DataDefend approaches vendor risk for Indian compliance specifically.