Vendor Risk Management
Checking and monitoring the privacy and security of the vendors that handle your data.
Vendor risk management is the habit of checking, before and during a contract, whether the companies that handle your personal data can keep it safe and follow the law. It covers choosing, contracting, monitoring and exiting vendors.
Meaning of Vendor Risk Management
Because the fiduciary stays responsible for processors, it should assess vendors before signing, review them periodically and be ready to switch if risks grow.
Most organisations rely on outside providers for cloud hosting, payments, email, analytics, customer support, HR software and more. The DPDP Act recognises this reality by allowing Data Processors only under a valid contract under Section 8(2), while keeping the Data Fiduciary responsible for the processing under Section 8(1) and for security of data processed by a processor under Section 8(5). Vendor risk management is the discipline by which the Fiduciary turns that responsibility into a routine.
A typical programme has stages. Before onboarding, the organisation performs due diligence: what data will the vendor see, where, who are its sub-processors, what certifications and security controls does it have, what is its incident history. At contracting, it signs a DPA (see Rule 6 for the expectation on processor contracts). During the relationship, it monitors performance, reviews reports, re-assesses annually and tracks changes. At exit, it ensures deletion or return of data and closure of access.
Risk should be tiered. A vendor that stores your full customer database or processes payments is high risk and deserves a detailed questionnaire, evidence review and possibly an on-site or remote audit. A vendor that sees only business contact details is low risk and a short check will do. Sector regulators already demand such programmes in some fields: RBI's outsourcing expectations for banks and NBFCs, SEBI's for market intermediaries and IRDAI's for insurers. DPDP adds a personal data lens to those programmes.
Vendor risk management differs from procurement, which looks at price and service, and from information security assessment alone, which ignores the legal side such as purposes, transfers and rights support. It also differs from a data audit, which examines your own practice, while vendor reviews look outward at suppliers. In a Significant Data Fiduciary, vendor findings feed into the annual audit and Data Protection Impact Assessment under Rule 13.
Examples of Vendor Risk Management
A bank sends vendors a security questionnaire, reviews their certifications and audits high-risk ones annually.
A private bank grades its 200 vendors, audits the 15 that hold customer KYC data each year, accepts certification reports for medium-risk ones and sends a short attestation to the rest. A vendor that fails a security test is placed on a fix plan with a deadline.
A school buys a learning app for students. Before signing, it asks where data is stored, whether children's data is used for advertising, which would run into Section 9 restrictions, and what happens on contract end. It signs only after the vendor agrees to no tracking and deletion within 30 days.
A young marketplace relies on a payment gateway, a courier API and a customer-chat tool. It keeps a one-page record for each, with the DPA, contact for incidents, last review date and the date its certificate expires.
Why Vendor Risk Management matters
Vendors are a common route for breaches, and the Fiduciary cannot defend by blaming them. A weak vendor can lead to a breach of reasonable safeguards with penalties up to ₹250 crore and, if the vendor fails to alert you in time, to late notification to the Board and individuals with penalties up to ₹200 crore. A record of diligence shows that you took reasonable steps, which is relevant in any inquiry.
A working programme also saves money and time. It prevents lock-in with a poor supplier, speeds up renewals, supports enterprise sales that require evidence of vendor control, and lets you switch away from a vendor whose risks grow before an incident forces the issue.
How it works in practice
- 1Build an inventory of vendors from your data map and finance records, noting what personal data each can access and where it is processed.
- 2Tier the vendors as high, medium or low risk based on data volume, sensitivity, access depth and business criticality, and apply controls in proportion.
- 3Use a standard questionnaire and ask for evidence such as security certifications, penetration test summaries, business continuity plans and sub-processor lists. Score answers consistently and record any gaps accepted.
- 4Sign a DPA that covers instructions, security, breach notice within hours, sub-processors, rights support, deletion and audit rights, and keep vendors to those terms.
- 5Monitor on a schedule: annual review for high-risk vendors, review at renewal for others, and event-based review after any incident or major change.
- 6Plan the exit. Write down how data will be returned or deleted, ask for confirmation, and remove vendor accounts and integrations on the last day.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Assessing vendors only at onboarding. Risk changes as services and sub-processors change, so re-assess on a cycle.
Treating a security certificate as proof of privacy compliance. It speaks to controls, not to purposes, rights handling or cross-border transfers.
Overlooking free tools and plug-ins that staff adopt without approval; these shadow vendors often hold real customer data.
Having no exit plan, so data lingers with a former vendor for years.
Compliance tips
Link procurement to privacy: no purchase order for a service that touches personal data without a completed risk check.
Ask vendors to commit to an incident notice period shorter than your own reporting timeline under Rule 7, so you have time to act.
Share vendor risk reports with leadership every quarter and give them a clear list of overdue fixes.
Practise with your most critical vendor: run a joint incident drill and fix the gaps it reveals.
Common questions about Vendor Risk Management
Does the DPDP Act require vendor risk management?
It does not name it, but Section 8(1) keeps the Data Fiduciary responsible for processors, Section 8(2) requires a valid contract and Section 8(5) extends security duties to processed data. A vendor risk programme is the practical way to discharge those duties.
What should a vendor risk questionnaire ask?
Typical topics are the data handled, location of processing, sub-processors, security controls, [encryption](term/encryption), access management, incident history, certifications, breach notification time, deletion practice and support for rights requests. Tailor depth to the vendor's risk tier.
How often should I review vendors?
High-risk vendors are usually reviewed yearly and after any incident or major change. Medium-risk vendors can be reviewed at contract renewal, and low-risk vendors through a brief periodic check. The aim is to match effort to the risk the vendor carries.
Can I rely on the vendor's certification alone?
A certification is useful evidence about security controls, but it does not cover everything. You still need to check the scope, what the vendor does with your data, its sub-processors, and whether the contract meets your Section 8 duties.