TheDPDPAct.com -
Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Join Our WhatsApp Channel →The Data Processing Agreement is signed. The vendor contract has a privacy clause. The vendor has confirmed in writing that they implement appropriate security measures, process data only on documented instructions, and will notify the organization of any breach without delay.
What none of those documents tell you is whether any of it is true.
This is the structural gap in most vendor governance programs operating under the DPDP Act. Legal teams are drafting better Data Processing Agreements — that work is necessary and long overdue. What isn't happening with the same urgency is the verification step: confirming that the security measures a vendor has contractually committed to are actually in place, actually tested, and actually capable of meeting the obligations the Data Fiduciary is accountable for under the Act, regardless of who processes the data.
A vendor may take on operational responsibility. Under the DPDP Act, regulatory accountability cannot be delegated away. That fact — which sits at the heart of the Act's fiduciary framework — creates a direct technical obligation that no DPA clause can satisfy on its own.
The Accountability That Travels With the Data
Rule 6 of the DPDP Rules establishes that a Data Fiduciary is responsible for protecting personal data in its possession or under its control — including processing undertaken on its behalf by a Data Processor. The Fiduciary's Section 8(5) obligation to maintain reasonable security safeguards extends through the entire processing chain, not just to the organization's own systems.
The practical implication is one most organizations haven't fully absorbed: if a vendor breaches your data because they weren't encrypting it adequately, your organization's compliance failure is not "choosing a bad vendor." It's "failing to implement reasonable security safeguards" — the obligation that carries the Act's highest penalty of up to INR 250 crore. The vendor's contractual commitment to encrypt doesn't satisfy your obligation to verify that they do.
This is the gap the DPA cannot close. A contract clause is what you agreed to. A security assessment is what you confirmed.
The 72-Hour Problem Hidden Inside Vendor Relationships
The DPDP Act's breach notification requirement creates a specific, time-bound technical dependency on every vendor in an organization's processing chain. On becoming aware of a personal data breach, the Data Fiduciary must inform affected Data Principals without delay and report to the Data Protection Board within 72 hours — with an assessed impact and a description of remedial measures.
The critical word is "on becoming aware." If a vendor's environment is breached on a Monday and the vendor doesn't notify the Fiduciary until Thursday, the 72-hour window has already closed before the obligation to the Board even began. A DPA clause requiring the vendor to notify "promptly" or "without undue delay" is contractual language.
The technical questions that determine whether it's operationally meaningful are different:
Does the vendor have intrusion detection capability that would surface a breach in the first place?
Does their monitoring cover the specific systems holding your data?
Have they ever run a breach simulation to test whether their notification process actually works at the required speed?
Most vendor security assessments don't ask these questions, because most vendor security assessments aren't designed for DPDP compliance. They're designed for general vendor risk management, which is a related but different exercise. What the 72-hour window requires specifically is an assessment of the vendor's incident detection and response capability as it applies to your data, not their overall security posture in the abstract.
How to Actually Tier Vendors by Risk
Managing vendor security risk across an enterprise ecosystem requires tiering — the idea that high-risk vendors get full scrutiny while lower-risk vendors get a proportionate, lighter assessment. The principle is right. The execution is where most programs have gaps.
Risk tiering for DPDP purposes should be driven by two factors: the sensitivity and volume of personal data the vendor processes, and the systemic criticality of that vendor to the organization's DPDP compliance posture. These don't always coincide.
Tier 1 — Full security assessment.
Vendors processing sensitive personal data at meaningful scale: payroll administrators, HR platforms, CRM systems holding detailed customer records, healthcare data processors, payment gateways, background verification agencies. For these vendors, a full assessment covers encryption implementation (at rest and in transit, not just that it's promised), access control architecture (who within the vendor can reach your data and under what controls), breach detection capability (what monitoring exists, how fast incidents are surfaced), sub-processor arrangements (who the vendor themselves outsources to, and what security standards apply to that chain), and deletion and certification capability (can the vendor actually certify complete data destruction on contract termination, including from backups and sub-processor systems).
Tier 2 — Proportionate assessment.
Vendors processing lower volumes of non-sensitive data, or providing services with indirect data exposure. A proportionate assessment reviews security certifications (ISO 27001, SOC 2 Type II) as proxies for baseline controls, requires contractual representations with audit rights, and sets a schedule for periodic review rather than a full assessment at every renewal.
Tier 3 — Lighter self-certification.
Vendors with minimal personal data exposure. Self-certification against a standard questionnaire, with a contractual right to escalate to a full assessment if the relationship scope changes.
The segmentation exercise itself — deciding which vendor belongs in which tier — requires knowing what personal data each vendor actually processes. Which connects directly to the data flow mapping exercise: without knowing what data goes where, you cannot tier vendors accurately, which means you cannot calibrate assessment depth meaningfully, which means the governance program is working from assumptions rather than verified facts.
GenAI and SaaS Vendors: A Category That Needs Specific Treatment
The vendor risk picture has a specific dimension that didn't exist in most governance frameworks even three years ago and now sits in the middle of every enterprise technology stack: generative AI tools and the SaaS platforms that embed them.
The DPDP compliance risk here is particular. Employees entering personal data into AI platforms in the ordinary course of work — customer details into a drafting tool, patient information into a summarization tool, financial data into an analysis assistant — creates a processing relationship that may not be captured in the organization's formal vendor inventory at all. The AI vendor is processing personal data. The processing may not be subject to any DPA. The vendor may be using inputs to train or improve its models, creating a secondary use that was never consented to and never disclosed.
For AI vendors that are formally contracted, the assessment questions are specific:
Are inputs treated as confidential?
Is there a contractual prohibition on using client data for model training?
Where are inputs stored, for how long, and under what deletion terms?
Who is the underlying foundation model provider, and what data flows to them?
If the SaaS platform has its own AI features that process your data, are those features subject to the same contractual protections as the rest of the platform?
These questions require answers in the contract. They also require verification that the technical architecture matches what the contract says — because an AI vendor that contractually commits to not using inputs for training while technically having the capability to do so is a contractual representation, not a verified technical control.
The Exit Risk Nobody Assesses in Advance
One of the most consistently underestimated vendor security risks under the DPDP framework is what happens at contract end.
Rule 8 of the DPDP Rules requires Data Fiduciaries to erase personal data after the expiry of the specified retention period. That obligation applies to data held in vendor systems on the Fiduciary's behalf. The practical challenge: vendors rarely delete everything cleanly on contract termination. There are backup cycles that run on independent schedules. There are sub-processors who have copies the vendor itself may not fully control. There are logs that retain identifiable data long after the primary data has been deleted. And the vendor's written certification of deletion — which the DPDP Rules require — may be contractually available but technically unverifiable without an audit.
Assessing vendor exit risk before contract termination, rather than discovering it afterward, requires asking specific questions during the vendor security assessment:
What is the vendor's backup retention policy and can they delete from all backup cycles on request?
Which sub-processors hold copies of client data, and what deletion obligations apply to them?
What does the vendor's deletion certification actually confirm, and what technical evidence would support it?
These are questions the DPA should require the vendor to be able to answer. Confirming that they actually can is the assessment that verifies the answer.
What a DPDP-Specific Vendor Security Assessment Actually Produces
A vendor security assessment designed around DPDP compliance produces a different output from a general third-party risk questionnaire. It produces findings that map directly to the Fiduciary's statutory obligations — not a vendor risk score on an abstract scale, but a verified answer to the questions the Act will eventually require the Fiduciary to have answered.
Can this vendor meet the breach notification timeline that the Act requires of you?
Is the encryption this vendor contractually committed to actually implemented at the standard Rule 6 expects?
Are this vendor's sub-processors contractually bound to the same security obligations, and has that been verified?
If this vendor's contract ended today, would you be able to certify complete erasure of the data they processed?
For most organizations, the honest answer to at least some of these questions is "we don't know." The assessment is what converts "we don't know" into a verified position — either confirming that the vendor meets the standard, or producing a finding specific enough to remediate.
At ILLUME Intelligence, vendor security assessments designed around DPDP compliance obligations are a core part of how we approach third-party data governance — mapping the processing chain, tiering vendors by risk, assessing Tier 1 vendors against the specific technical requirements Rule 6 creates, and producing findings specific enough to inform both remediation and contract renegotiation. If your organization's vendor governance program is advancing on the DPA side without the technical verification layer underneath it, reach out to Illume to scope what that assessment looks like for your vendor ecosystem.
