How to manage third-party vendor risk under DPDP
Your vendor's data practices are your compliance risk. Here is how to build a third-party risk management programme for DPDP.
How do you build a vendor data inventory?
List every external service, software platform, and service provider that accesses, processes, or stores personal data on your behalf. Include: cloud infrastructure (AWS, Azure, GCP — even if you host your own software); SaaS platforms (CRM, HRMS, marketing automation, analytics, customer support); payment processors; background verification agencies; data entry outsourcing firms; analytics and research agencies; communication platforms (email, SMS, WhatsApp APIs); and any API integration that sends or receives personal data. Most organisations discover 2–3x more third-party data sharing than they expected when they do this exercise properly.
How do you classify vendors by risk?
Use a three-tier model: Tier 1 (Critical) — vendors with access to large volumes of sensitive personal data (health, financial, biometric) or who process data for core business functions. Examples: payroll system, customer database, payment processor. Require full DPA, security assessment (SOC 2 or ISO 27001 certificate), annual review, and DPO/CISO sign-off. Tier 2 (Standard) — vendors with access to moderate volumes of personal data for operational purposes. Require DPA and security questionnaire. Tier 3 (Low) — vendors with minimal or no personal data access. Lighter-touch review.
What is a vendor security questionnaire and what should it cover?
A security questionnaire is a structured set of questions you send to a vendor before onboarding (and periodically thereafter) to assess their data security practices. Cover: data security controls (encryption, access management, MFA); incident response capability (do they have a breach response plan? How long to notify you?); sub-processor practices (what sub-vendors do they use? Do they have DPAs with them?); geographic data storage (where is our data stored?); security certifications (ISO 27001, SOC 2, PCI DSS); and recent audits (can they provide their latest penetration test report?). For Tier 1 vendors, request documentary evidence rather than self-certification.
How do you monitor vendors on an ongoing basis?
Vendor risk is dynamic. Monitor continuously: check vendor security news feeds for breach reports; receive notification of material changes to their privacy policy or sub-processor list; review their security certifications on renewal; conduct annual vendor risk re-assessments for Tier 1 vendors; review vendor incident notification logs (how quickly did they tell you about incidents?); and check that your DPA is still current if their service model changes. Some vendor risk management platforms (OneTrust, SecurityScorecard) automate continuous monitoring for enterprise programmes.
What should you do when a vendor reports a security incident?
When a vendor notifies you of a breach involving your data: immediately assess the scope and the type of personal data affected; determine if the breach reaches the threshold for Board notification and data principal notification under DPDP; coordinate your notification obligations with the vendor to ensure your messages to the Board and affected individuals are factually consistent; preserve evidence of the vendor's notification (timestamp, content) for your own records; and after the incident, review whether the vendor's security controls were adequate and whether to continue the relationship. The vendor's DPA obligations run to the quality of their breach response.
How do you handle vendors who refuse to sign a DPA?
A vendor who refuses to sign any data protection agreement should be a significant red flag. If you cannot avoid the vendor (for example, a dominant market player), escalate the issue within your organisation and document that you sought a DPA and were refused. Mitigate: minimize the personal data shared with this vendor; avoid sharing sensitive personal data; put compensating controls in place (additional encryption on data sent to the vendor, minimised API access). Work with your legal team to assess whether the vendor relationship is legally viable under DPDP without a DPA. For non-critical vendors, find alternatives willing to enter into a DPA.
Frequently asked questions
Are all SaaS tools we use Data Processors?
A SaaS tool is a Data Processor when it processes personal data solely on your instructions and for your purposes. If the SaaS tool uses the data for its own purposes — aggregating across customers for benchmarking, training AI models on customer data, selling anonymised data — it steps into the Fiduciary role for those uses. Most SaaS tools will claim to be Processors in their DPA terms. Read the DPA carefully: if their privacy policy allows using your data for their own product improvement, they may be acting as a joint Fiduciary for those uses.
Do we need a DPA with our legal counsel or auditor who receives client data?
When your legal counsel or auditor processes personal data on your behalf — reviewing a data breach, auditing your HR records — they are Data Processors for that engagement. You should have a DPA or data protection clause in your engagement letter covering confidentiality, purpose limitation (they process the data only for the engagement), and security. Professional services firms are increasingly familiar with DPA requirements from their enterprise clients — most large law firms and audit firms have standard DPA addenda they can sign.
What is a 'fourth party' and why does it matter for DPDP vendor risk?
A fourth party is a vendor's vendor — the sub-processors and service providers your vendors use to deliver their services. Your cloud CRM vendor uses AWS for hosting (a sub-processor); your payroll vendor uses a bank API for salary disbursement; your marketing automation tool uses Twilio for SMS. Fourth parties process your customers' personal data even though you have no direct relationship with them. Your DPA with your vendor should require them to: name their significant sub-processors; have DPAs with those sub-processors; notify you when sub-processors change; and take responsibility for their sub-processors' compliance.
Build your DPDP vendor risk management programme
Niti Bharat's Vendor Risk Assessment covers vendor data inventory, risk tiering, DPA gap analysis, security questionnaire, and ongoing monitoring framework for DPDP compliance.
Start Vendor Risk Assessment