Third-Party Risk Management Under DPDP: An Enterprise Guide

What Is Third-Party Risk Management Under DPDP?

Third-party risk management under DPDP is the process of identifying vendors that handle personal data on your behalf and rating the risk each carries. Contractual safeguards and ongoing verification form part of the same process. Each step helps a Data Fiduciary meet its accountability for processing carried out by a Data Processor.

Take a retail brand that sends offers through an SMS gateway. The Act defines a Data Fiduciary as any person who decides the purpose and means of processing. Here that is the brand, because it chooses which customers receive which offers and sets the schedule for each campaign run. Delivery on instruction is all the gateway does, which makes it a Data Processor. Customers who receive the messages are Data Principals, the individuals to whom the personal data relates.

Roles are assigned activity by activity. Should the same gateway build an audience of its own from the mobile numbers it receives, it acts as a Data Fiduciary for that use. That use gets a separate row in the register.

What the DPDP Act Requires When You Use Data Processors

Subject to the Act's scope and exemptions, six obligations reach vendor relationships. Paragraphs below describe the regulatory position. Methods after them are OneConsent's operational recommendations.

Responsibility for compliance with the Act and the Rules rests with the Data Fiduciary, for processing it undertakes and for processing a Data Processor undertakes on its behalf. A services agreement that tries to shift that responsibility to the vendor leaves the position unchanged.

Engaging a Data Processor for activity linked to offering goods or services to Data Principals requires a valid contract. Under the Rules, the security safeguards include an appropriate provision in that contract, wherever applicable.

When a vendor suffers an incident, the notification duty stays with the brand. An initial intimation reaches the Board without delay, with further details within 72 hours of the brand becoming aware (or within a longer period the Board allows on written request). Each affected Data Principal receives notice from the business. No separate deadline applies to the vendor under the Rules, so only the contract can fix the vendor's reporting window.

Consent withdrawal travels down the vendor chain: after a Data Principal withdraws consent, the business ceases processing within a reasonable time and causes its Data Processors to do the same. Processing continues only where a law requires or authorises it. Erasure follows on withdrawal, or once it is reasonable to assume the purpose is no longer served, whichever is earlier. Data Processors erase on the same trigger unless a law requires retention.

Deletion instructions need one more check against the Rules. For Seventh Schedule purposes, specified personal data and the associated traffic data and logs must be retained for a minimum of one year. Instructions to vendors have to account for that period where it applies.

Data Principals can also ask who receives their data. A Data Principal who asks receives the identities of other Data Fiduciaries and Data Processors with whom the business has shared the data. Alongside the answer goes a description of that data, subject to a limited exception in the Act. Your vendor register is the document that supplies it.

The provisions above and the related Rules commence on 13 May 2027 under notifications G.S.R. 843(E) and G.S.R. 846(E). Your team can plan the contract review around that date.

Building a Vendor Register From Actual Data Flows

Vendors surface from unexpected places. A webinar tool bought by marketing and a chat widget installed by support both receive personal data, though neither may have passed through procurement. DPDP vendor compliance therefore starts from data flows in each team, and the register records:

1.       Service provided and its internal owner.

2.       Personal data categories shared and the approved purpose.

3.       Systems and storage locations involved, with any onward recipients.

4.       Vendor role for that activity and the governing contract.

5.       Security evidence and retention terms, with the next review date.

Onward recipients matter because instructions have to follow the data. If the CRM provider stores records with a cloud host and sends messages through a gateway, an incident notice or a deletion request reaching the CRM provider has two more hops to make.

Ownership decides whether the register stays current over several review cycles. Procurement runs the contract workflow and legal reviews the terms. IT security holds the evidence, and the business owner decides purpose and retention.

Change reviews start from the same register. Suppose marketing wants to use order history from the support desk tool for a festive campaign: the reviewer checks the purpose in the notice and the ground for processing before anyone exports the campaign list.

Rating Vendor Risk by Access and Impact

A vendor risk assessment compares the data a vendor receives with the access it has and the harm that misuse or loss could cause individuals. Data volume and sensitivity set the baseline for the rating. Onward sharing and retention periods adjust it, as does the importance of the service to daily operations.

Three tiers, from high to low, are sufficient once the criteria are written down and applied the same way each time. Identity documents and transaction histories put a verification platform in the high tier. A courier that holds customer names and delivery addresses belongs in the middle tier, and a design agency that sees only business contact details falls in the low tier. Employee and business contact data enter the assessment whenever they reach a vendor.

Reviewers record the reason for each rating and the evidence behind it. Later reviewers can then reassess without starting over.

What a Data Processing Agreement Should Cover

A data processing agreement records a processor's instructions and safeguards. Services contracts can carry the same terms in a schedule. Legal review moves faster when each clause points to a task that your team can name and assign.

Typical clauses cover permitted processing on documented instructions and confidentiality duties for the vendor's staff. Access controls and incident escalation come next, followed by approval of onward providers. Remaining terms govern help with Data Principal requests and what happens to the data when the service ends.

Incident terms set the clock for the business's own notification duties. Because the Board hears from the business without delay and receives details within 72 hours, the vendor's reporting window has to leave the response team time to assess the incident first. Retention terms separate retention the law requires from continued use of the data for the vendor's own marketing or analytics. Suppose a loyalty vendor receives mobile numbers and purchase histories for a festive campaign: the clause on onward providers decides whether its SMS gateway may handle those numbers without prior approval.

Read next: Third-Party Vendor Risk Under DPDPA: What You Must Contractually Require of Processors

Evidence and Reassessment in Third-Party Risk Management Under DPDP

A signed agreement is the starting record for each vendor, and evidence shows whether the vendor follows it. Useful items include a completed vendor risk assessment and audit findings. Security documentation and written confirmation of a completed deletion belong in the same file. Each item carries a date and the service it covers. A certificate that covers the vendor's hosting service does not extend to its customer support tooling. Read the scope statement and the issue date before relying on it.

Each gap receives an owner, a due date and an agreed condition for closing it. An incomplete retention clause, for example, stays open until the parties sign the revised contract and the team has checked the vendor's deletion routine. Legal requirements that remain open stay apart from commercial or operational risks the business may accept after review. Any vendor activity with no ground for processing needs correcting or stopping.

Oversight continues after onboarding. A vendor that adds an onward provider for SMS delivery or moves storage to another region triggers a change review, as do incidents and contract renewals. Reviewers can keep the change review narrow, covering only the affected controls, then widen it when the change warrants. Each outcome goes into the register with an updated rating and any follow-up action. Over time, the register shows each assessment and each change, so open decisions stay visible.

Audit Frequency and Measures for Vendor Oversight

No universal vendor audit schedule exists in the framework. Additional audit and impact assessment duties on a twelve-month cycle fall on Significant Data Fiduciaries, whom the Central Government notifies. Other organisations set review frequency from the vendor's role and the data involved, along with any sector requirements that apply. Teams document the choice next to contractual audit rights and security evidence.

Four measures show whether third-party risk management under DPDP is working in practice. None of them is a requirement of the Act. The register can report each one:

1.       Share of vendors with a current processor contract on file.

2.       Open gaps grouped by age, with the owner named for each.

3.       Share of reassessments completed within the planned review window.

4.       Deletion confirmations received after a vendor exit or a consent withdrawal.

Where DPDP Compliance Software Supports Vendor Assessments

Once a vendor questionnaire has circulated by email among reviewers in several teams, three people may hold three versions of the answers. Ratings then become hard to compare across teams. Software helps when a reviewer can open one record and see the vendor's role, the latest rating and every pending action.

The OneConsent Third Party Risk Management module offers AI-based vendor risk assessments and analysis of vendor questionnaires. Alongside that, the module reviews contracts and documents to identify privacy and data processing gaps. Findings from those reviews feed the assessment stage described above.

Run a representative vendor contract and assessment pack through any third-party risk management software or DPDP compliance software for a fair test. Check whether the flagged gaps are relevant and how reviewers validate each finding. Confirm which capabilities come with the proposed deployment. Compliance itself depends on the organisation's processing activities and safeguards. Contract decisions and processing arrangements remain with legal and business owners.

Starting Third-Party Risk Management Under DPDP With One Vendor List

One agreed list of vendors and the processing each one performs is the first deliverable. Privacy and legal teams, together with security and procurement, prioritise assessments from that list and give each corrective action a named owner.

Compare your list with current contracts and security evidence, then with retention terms. Documented reviews, run in sequence, give your DPDP readiness planning a working basis for the period before 13 May 2027 and for oversight after it.

Review Your Vendor Oversight With the OneConsent Team

If you want a second view on your vendor register and processor contracts, the OneConsent team can review them with you and share findings specific to your organisation. Explore OneConsent DPDP compliance solutions to see how the platform supports vendor assessments. You can also book a vendor demo to test it against one of your own contracts.