Vendor risk management under the DPDP Act is the process of assessing, monitoring, and controlling how third-party vendors handle personal data on your behalf. Under India’s Digital Personal Data Protection Act, 2023, you (the data fiduciary) stay liable for every piece of personal data your vendor touches, even if that vendor causes the breach. The penalty ceiling? ₹250 crore. Per violation. And the May, 2027 enforcement deadline is closer than most compliance teams think.
This piece breaks down the specific obligations, the real penalties, the due diligence steps that actually matter, and where most organizations still have blind spots in their vendor data flows.
Why vendor risk management matters under DPDP
Here’s the part that catches most organizations off guard.
Section 8(5) of the DPDP Act makes it explicit: a data fiduciary is responsible for compliance even when processing is carried out on its behalf by a data processor. This responsibility cannot be contractually transferred. The vendor cannot be pointed to as the responsible party. The data fiduciary is approached first by the Data Protection Board of India (DPBI).
And this accountability is absolute. If customer contact data is exposed through a breach suffered by your CRM provider, the regulatory consequences are borne by the data fiduciary. If employee salary records are mishandled by a payroll vendor, penalties are imposed on the data fiduciary. If data is processed beyond the consented purpose by a marketing agency, enforcement action is directed toward the data fiduciary by the DPBI.
The average cost of a data breach in India hit ₹22 crore (roughly $2.6 million) in 2025, according to Seqrite’s analysis of recent mega breaches. Most of those breaches involved third-party vectors: contractors with too much access, SaaS tools with unmonitored integrations, shadow data transfers between vendors.
What the DPDP Act actually requires for vendor management
The DPDP Act and the DPDP Rules 2025 lay out specific obligations. They’re worth knowing precisely, because the penalties map directly to these requirements.
Data processing agreements are mandatory: Under Rule 6, a data processor must be engaged by every data fiduciary only through a valid contract. That contract must define the scope of processing, the security safeguards the vendor must maintain, breach notification timelines, sub-processor approval requirements, and data deletion obligations at contract termination. A generic MSA with a one-line privacy clause doesn’t count.
Security safeguards must extend to vendors: “Reasonable security safeguards” are required to be implemented under Section 8(5) to prevent personal data breaches. That obligation doesn’t stop at your firewall. It extends to every vendor touching personal data. Encryption, access controls, monitoring, audit trails, all of it must be contractually mandated and practically verified.
Breach notification follows a dual timeline: When a vendor breach occurs, the 72-hour notification period to the DPBI is triggered at the moment awareness is established, not when notification is received from the vendor. On top of that, CERT-In’s 6-hour reporting mandate applies in parallel for cybersecurity incidents. Two regulators, two clocks, one breach.
Consent withdrawal must propagate: Under Section 6, when consent is withdrawn by a data principal, processing must be stopped and the cessation of processing by data processors must be ensured.
Vendor due diligence under the DPDP Act: what to check before onboarding
Vendor due diligence under DPDP isn’t a one-time checkbox. It starts before onboarding and runs through the entire relationship. Here’s what a real due diligence process looks like.
Before any agreement is signed, the data should be mapped. What personal data will this vendor access? Customer PII? Employee records? Financial data? Health information? The sensitivity of the data determines the tier of scrutiny. A cloud provider hosting your customer database needs a full security assessment. Your office supplies vendor probably doesn’t.
Assess their security posture: Certifications such as ISO 27001 or SOC 2 should be reviewed. However, reliance should not be placed solely on these certifications. Evidence should also be requested at rest and in transit, role-based access controls, penetration testing results, and incident response procedures. If the vendor can’t produce these, that’s your answer.
Information regarding sub-processors should be obtained: This is where many organizations get blindsided. Your vendor uses AWS for hosting. AWS uses sub-processors. Your vendor’s analytics partner processes data in Singapore. Under DPDP, you need to know about every entity touching personal data in the chain. Shadow sub-processors, vendors who delegate data processing to another party without telling you, are one of the highest-risk scenarios under the Act.
Deletion capability should be verified: Can the vendor actually delete all copies of personal data on demand? Including backups, logs, test environments, archived data? Many vendors can’t. Their systems weren’t built for it. And under DPDP, “our architecture makes it difficult” isn’t a defense.
Cross-border data flows should be assessed: DPDP allows data transfers to countries not on the government’s restricted list. But the fiduciary still bears contractual and security obligations. If your vendor routes data through jurisdictions you haven’t assessed, you’re carrying risk you haven’t priced.
The 72-hour breach clock: how vendor breaches trigger your notification obligation
This is the scenario that keeps DPOs up at night.
A vendor’s system gets compromised on a Monday. The breach was detected on Wednesday. Notification is provided on Friday. Your 72-hour notification clock to the DPBI started Friday, not Monday. But you’ve already lost 4 days of containment time. You don’t have access to the vendor’s logs. You don’t know the blast radius. And you need to send a detailed report to the Board that includes the nature of the breach, the data exposed, the number of affected individuals, and the steps taken.
At the same time, if the breach is classified as a cybersecurity incident, CERT-In’s 6-hour reporting obligation is triggered separately. This dual reporting requirement is where preparation separates the organizations that survive enforcement from those that don’t. Immediate breach notification should be required within the data processing agreement, not “reasonable” notice, not “within 5 business days.” Immediate. And your own incident response playbook needs to account for vendor-origin breaches specifically.
The penalty for failure to notify the DPBI can be up to ₹200 crore. The penalty for inadequate security safeguards that led to the breach can be up to ₹250 crore. These penalties can be stacked. Multiple penalty tiers can be triggered by a single vendor breach.
Where most vendor risk programs still fall short
Point-in-time assessments. That’s the gap.
Vendor security assessments are run by most organizations at onboarding and sometimes annually afterward. A questionnaire is collected, a SOC 2 report is reviewed, and the documentation is filed away. Between those assessments, infrastructure may be changed by the vendor, sub-processors may be added, access controls may be modified, and new SaaS tools that touch your data may be introduced. None of these changes is caught until the next review cycle, if it is caught at all.
The DPDP Act doesn’t explicitly mandate continuous monitoring. But Section 8(5) requires “reasonable security safeguards,” and the DPBI will assess what’s “reasonable” based on factors like the volume and sensitivity of data, the nature of processing, and the risk to data principals. A vendor handling 10 million customer records with annual-only oversight? Good luck arguing that’s reasonable when the Board is calculating your penalty.
The gap between periodic vendor assessments and real-time data visibility is where breaches occur. Unauthorized data flows may remain undetected for months. Customer data may also be used by a vendor for model training or benchmarking without the fiduciary’s knowledge. This is where data-level visibility is recognized as a real operational need. If the movement of personal data across the vendor ecosystem cannot be seen in real time, a blind spot exists in the vendor risk management program that cannot be fixed by any checklist. Matters.AI’s data lineage and DDR capabilities are built for exactly this problem: continuously tracking where sensitive data flows across cloud, SaaS, and third-party environments so you can detect unauthorized access or movement before it becomes a breach.
Building a DPDP-ready vendor risk management program
If you’re starting from scratch (or rebuilding from a pre-DPDP baseline), here’s the practical sequence.
1. Build your vendor data inventory: List every vendor that accesses, processes, or stores personal data. Map each to the data types they handle, the business function they support, and the sensitivity tier. Most organizations discover vendors they didn’t know were processing personal data during this exercise.
2. Tier your vendors by risk: Large volumes of sensitive data, critical processing functions, access to customer-facing systems. Medium risk: moderate data volumes, standard processing. Low risk: limited data, minimal processing. Your due diligence depth scales with the tier.
3. Rewrite your data processing agreements: Strip the boilerplate. Every DPA needs: defined processing scope and purpose, mandatory security safeguards (encryption, access controls, audit logs), breach notification within hours (not days), sub-processor approval requirements, audit and inspection rights, data deletion/return on termination, and specific DPDP compliance obligations.
4. Implement continuous monitoring: Go beyond annual questionnaires. Track vendor security posture changes, monitor data access patterns, flag anomalous behavior. This is where most programs need tooling support, because doing it manually across 50+ vendors doesn’t scale.
5. Test your breach response: Run a tabletop exercise specifically around a vendor-origin breach scenario. Walk through: how does the vendor notify you? Who receives the alert? How quickly can you assess scope? Can you meet both the CERT-In and DPBI timelines? If you can’t answer these questions clearly, you’re not ready.
6. Document everything: The DPBI considers “good-faith compliance efforts” as a mitigating factor in penalty assessments. Documented processes, audit trails, vendor assessment records, and tested incident response plans are your strongest defense if enforcement hits.
How DPDP vendor compliance intersects with RBI and SEBI
For BFSI organizations, the compliance picture compounds.
The RBI Master Direction on IT Governance (2024) mandates that tight oversight over outsourcing arrangements be maintained by regulated entities. Mandatory risk assessments before vendor onboarding, annual vendor audits, audit trail maintenance, and data localization requirements for payment system data are included in these obligations.
SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) requires market infrastructure institutions to treat supply chain risks as a board-level priority.
When a vendor breach hits a bank or NBFC, it’s a regulatory event on two (sometimes three) axes simultaneously: DPDP, RBI, and potentially SEBI. Each with its own notification requirements, its own investigation process, and its own penalty exposure. The organizations that handle this well are the ones that have mapped these overlapping obligations in advance and built a unified incident response workflow that satisfies all of them.
The May 2027 deadline is a governance milestone, not a paperwork exercise
Full enforcement of the DPDP Act’s substantive provisions kicks in on May 13, 2027. That sounds like it’s far away. It isn’t.
Renegotiating vendor contracts takes months. Building continuous monitoring infrastructure takes months. Training cross-functional teams on breach response takes months. If your vendor risk management program still runs on annual questionnaires and generic MSAs, the runway is shorter than you think.
The organizations that come out of this well are the ones treating 2026 as the implementation year, not the planning year. Map your vendor data flows. Rewrite your DPAs. Test your breach response. Build the visibility layer that tells you where personal data actually goes across your vendor ecosystem.
Because when the DPBI starts processing complaints (and they will), the question won’t be whether you had a policy. It’ll be whether you had control.
