DPDP Vendor Assessment Framework for AI and Data Tools

Why Vendor Assessment Matters for DPDP

Under DPDP, you remain responsible for personal data processed by your vendors. Section 8(2) holds Data Fiduciaries accountable for ensuring their data processors comply with the Act's provisions. A vendor breach can become your breach notification obligation.

For AI vendors specifically, the risks are amplified: AI APIs process your users' personal data in plaintext, model training may use your data, and vendor security practices directly affect your DPDP exposure.

The Assessment Framework

Section A — Data Processing Transparency: Does the vendor have a clear DPA? Is their sub-processor list published and maintained? Do they provide data residency options? Can they confirm they don't train on your API data? Section B — Security Controls: What certifications do they hold (ISO 27001, SOC 2 Type II, CSA STAR)? What is their breach notification SLA? Do they offer audit logs and monitoring? Section C — Data Principal Rights: Can they support DPDP erasure requests (delete your users' data on demand)? Do they provide data export in machine-readable format? What is their response time for DSR requests?

Section D — Contract Terms: Does their ToS allow training on your data? Does their DPA meet DPDP standards? Is Indian law governing their liability? Section E — India-Specific: Do they have India-region infrastructure? Have they published a DPDP readiness statement? Are they registered with any Indian regulatory body?

Red Flags and Deal-Breakers

Automatic deal-breakers for BFSI and healthcare: no DPA available, trains on API data by default, no data deletion mechanism, no India region option. Yellow flags requiring mitigation: DPA exists but India law isn't governing jurisdiction (use redaction gateway as compensating control), SOC 2 Type I but not Type II (require upgrade commitment), no published sub-processor list (require contractual notification of changes).

For AI vendors with no DPA (common in early-stage startups), the safest approach is to redact all PII before their API receives data — then the absence of a DPA matters less because no personal data reaches them.

Compliance operational checklist

DPDP Vendor Assessment Framework for AI and Data Tools should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.