Third-Party Vendor Risk Under DPDP: Your Vendor's Breach Is Your Breach

Who this is for: procurement leads, vendor managers, compliance heads and legal teams who approve, contract and oversee the vendors that handle personal data.

A typical mid-sized Indian company shares personal data with dozens of vendors: cloud hosting, CRM, email and SMS platforms, payroll, customer support tools, analytics, payment gateways, KYC providers, call centres and marketing agencies. Each one is a place where personal data can be mishandled, breached or kept long after it should have been deleted.

Under the DPDP Act, that risk stays with you. This guide explains what the law requires of your vendor relationships and how to build a vendor risk programme that holds up. For the wider legal framework, see The DPDP Act, Explained.

You stay liable: what the Act says

The DPDP Act places obligations primarily on the Data Fiduciary, the entity that decides why and how data is processed. A vendor acting on your instructions is a Data Processor. Four provisions define the relationship:

• Section 8(1): the fiduciary is responsible for complying with the Act, including for any processing undertaken on its behalf by a processor.
• Section 8(2): a fiduciary may engage a processor only under a valid contract, and only to process data in connection with offering goods or services to Data Principals.
• Rule 6: the reasonable security safeguards the fiduciary must take include "appropriate provision in the contract" with the processor for taking those safeguards.
• Section 8(5): the fiduciary must protect personal data in its possession or under its control, which includes data processed on its behalf.

The consequence is simple: your vendor's breach is your breach. If a payroll provider loses employee data, it is your organisation that must notify the affected employees and the Data Protection Board, and your organisation that faces a penalty of up to ₹250 crore if reasonable safeguards were not in place.

Where vendors affect your other obligations

Vendor risk is not only about security. Almost every DPDP obligation runs through your vendors:

A vendor programme that only checks security certifications at onboarding will miss most of these.

The vendor risk lifecycle

A defensible programme covers six stages.

1. Inventory

You cannot manage vendors you do not know about. Build the vendor list from your Record of Processing Activities, then cross-check it against procurement, finance and accounts payable records to find tools bought on corporate cards without review. Free and freemium SaaS tools are a common blind spot.

2. Tier

Not every vendor needs the same scrutiny. Tier vendors by the risk their processing creates:

3. Due diligence

Before sharing data, assess whether the vendor can meet your obligations. Key questions include:

• What personal data will the vendor process, for what purpose, and where?
• Does it meet the Rule 6 safeguards: encryption or masking, access control, logging and monitoring, backups, and log retention?
• Does it use sub-processors, and where are they?
• How quickly will it notify you of a breach, and what information will it provide?
• Can it support access, correction and erasure requests, and certify deletion?
• What independent evidence (certifications, audit reports, penetration tests) can it provide?

4. Contract

Section 8(2) requires a valid contract. For DPDP purposes, it should cover at least:

1. processing only on documented instructions, and only for the specified purpose
2. the Rule 6 security safeguards, stated specifically
3. breach notification to you within a fixed, short window, with the information you need for Rule 7
4. support for withdrawal, access, correction and erasure requests
5. restrictions on sub-processing, with flow-down of the same obligations
6. disclosure and approval of processing locations and cross-border transfers
7. deletion or return of data at the end of the engagement, with certification
8. audit and information rights
9. cooperation with the Data Protection Board and with your investigations
10. allocation of liability and indemnities that reflect your exposure

5. Monitor

Onboarding due diligence describes a vendor on one day. Risk changes after that. Review critical and high-tier vendors at least annually, and also whenever a trigger event occurs:

• the vendor suffers a security incident
• the vendor changes ownership, hosting location or key sub-processors
• you start using the vendor for a new purpose or new data category
• the vendor's certifications lapse
• a regulatory change affects the service, such as a new transfer restriction under Section 16

6. Offboard

When a contract ends, make sure data is returned or erased, obtain written certification, revoke access, and update your ROPA. Data left with a former vendor is still your responsibility.

Common vendor risk mistakes

• Treating the vendor's certification as compliance. ISO 27001 says something about security controls. It says nothing about whether the vendor will honour withdrawals or erase data on request.
• Contracts that predate the DPDP Act. Most existing agreements lack withdrawal, erasure and fast breach-notification terms.
• Ignoring sub-processors. Your data often sits two or three vendors away from the company you contracted with.
• No offboarding. Data retained by former vendors is a hidden breach waiting to happen.
• Annual reviews only. The most important review is the one triggered by an incident.

How ConsentifyAI helps

ConsentifyAI connects vendor risk to the rest of your DPDP programme. Vendors are linked to the processing activities in your ROPA, so you always know which vendor holds which personal data, for which purpose and where. Due diligence, contract status and review dates are tracked per vendor tier, and consent withdrawals and erasure requests can be routed to the vendors that need to act on them, with evidence recorded in the audit trail.