Vendor risk management under the DPDP Act starts with a basic legal principle: engaging a third party to process personal data does not transfer the Data Fiduciary's responsibility under the law. When a vendor acts as a Data Processor, the Data Fiduciary remains responsible for processing carried out on its behalf.
Section 8(1) of the DPDP Act expressly establishes this responsibility, while Section 8(2) requires the Data Fiduciary to engage a Data Processor under a valid contract for processing related to offering goods or services to Data Principals.
Vendor governance thus becomes an important part of DPDP compliance. Businesses need to know which vendors actually process personal data, what they do with it, what safeguards protect it, and whether their processes can support requirements such as breach notification, consent withdrawal, and erasure.
In this guide, you will learn :
- Which vendors qualify as Data Processors under the DPDP Act
- What responsibility remains with the Data Fiduciary when processing is outsourced
- What the law actually requires from a DPDP Data Processor contract
- Which security safeguards need to extend to vendor processing
- How consent withdrawal and erasure should reach processors
- What businesses need to do when a vendor suffers a personal data breach
- How foreign and cloud vendors should be handled
- Which common DPDP vendor compliance practices are useful but are not expressly mandated by the Act
Who Is Responsible When a Vendor Processes Personal Data?
The DPDP Act creates a clear accountability structure between the organization that controls the processing and the vendor that performs it. This distinction matters when a processor makes an error, experiences a security incident, retains data beyond the required period, or cannot act on an instruction from the Data Fiduciary.
Section 8(1) places responsibility for compliance with the DPDP Act and its Rules on the Data Fiduciary for processing undertaken by the organization itself or on its behalf by a Data Processor.
Section 8(2) allows a Data Fiduciary to engage a Data Processor for covered activities related to offering goods or services to Data Principals only under a valid contract.
Together, these provisions establish two important responsibilities for businesses using processors:
- Retain accountability: Processor activity remains within the Data Fiduciary's compliance responsibility.
- Establish a valid contractual relationship: Covered processor engagements must be supported by a valid contract.
This is the foundation of third-party risk management under the DPDP Act. Before assessing a vendor's security controls or negotiating additional contractual safeguards, an organization first needs to establish whether the vendor is processing personal data on its behalf and understand the responsibilities that follow from that relationship. A DPDP compliance checklist can support businesses in managing these DPDP obligations.
Key Takeaway : Outsourcing the work does not outsource the Data Fiduciary's responsibility.
DPDP Act and Rules That Matter for Vendor Management
Vendor obligations under the DPDP Act are scattered across several sections and the Digital Personal Data Protection Rules, 2025. The table below maps each provision to what it actually means for vendor management, which is the fastest way to see how DPDP vendor risk management connects back to the statute rather than to generic third-party risk frameworks borrowed from other jurisdictions.
| Provision | What it says | Vendor-management impact |
|---|---|---|
| Section 2(k) | Defines a Data Processor as a person processing personal data on behalf of a Data Fiduciary | Determine which vendors actually process personal data on your behalf |
| Section 6(6) | After consent withdrawal, the Data Fiduciary must cease and cause its processors to cease the relevant consent-based processing, subject to applicable legal requirements | Withdrawal workflows must extend to processors |
| Section 8(1) | The Data Fiduciary remains responsible for processing performed on its behalf | Processor failures can create compliance exposure for the Data Fiduciary |
| Section 8(2) | A Data Processor used for covered processing must be engaged under a valid contract | Processor relationships require contractual controls |
| Section 8(5) | Personal data must be protected through reasonable security safeguards, including processing by a Data Processor | Vendor security needs to be considered within the overall control environment |
| Section 8(6) | The Data Fiduciary must notify the Board and affected Data Principals of a personal data breach in the prescribed manner | Vendor incident escalation must support the Data Fiduciary's reporting obligations |
| Section 8(7) | The Data Fiduciary must erase personal data when required and cause its Data Processor to erase data supplied for processing | Deletion and offboarding procedures need processor-level execution |
| Section 11(1) | In covered access requests, the Data Principal can obtain identities of Data Fiduciaries and Data Processors with whom data has been shared | Processor relationships need to be traceable |
| Section 16 | The Central Government may restrict transfer of personal data to specified countries or territories | Vendor locations and international processing arrangements need to be tracked |
| Rule 6 | Prescribes minimum reasonable security safeguards | Processor contracts and technical assessments should address the applicable safeguards |
| Rule 7 | Prescribes personal data breach notification requirements | Vendor escalation processes should provide information early enough for required notifications |
| Rule 8 | Sets requirements around specified-purpose retention and processing logs, including processing carried out on behalf of a Data Fiduciary | Processor retention and deletion need to be coordinated |
| Rule 13 | Adds DPIA and audit requirements for Significant Data Fiduciaries | Vendor-related processing should be considered within the organization's broader risk assessment |
| Rule 15 | Governs transfers of personal data outside India subject to requirements specified by the Central Government | Organizations need visibility into overseas processing and applicable transfer requirements |
These provisions form part of a broader DPDP compliance framework. A DPDP compliance solution can help organizations review the requirements in depth alongside their vendor-specific controls.
Not Every Vendor Is a Data Processor
When Does a Vendor Become a Data Processor Under the DPDP Act?
A business may work with hundreds of third parties across technology, operations, finance, marketing, logistics, and other functions. Only some of them will fall within the definition of a Data Processor under the DPDP Act.
Section 2(k) defines a Data Processor as a person who processes personal data on behalf of a Data Fiduciary. The key question is therefore whether the vendor is processing personal data for the Data Fiduciary and as part of the processing activity the Data Fiduciary has determined.
This makes vendor classification an important first step in third-party vendor management under the DPDP Act. A vendor's access to a company's systems or services alone does not automatically make it a Data Processor. The nature of the processing relationship needs to be examined.
Consider these examples:
| Vendor relationship | Likely DPDP position |
|---|---|
| HR software provider managing employee records on behalf of an organization | Data Processor |
| Managed security service provider accessing user information while providing monitoring services | Data Processor |
| Cloud hosting provider storing application and customer data for a business | Data Processor |
| Courier company receiving a customer’s name and delivery address to fulfill an order | Could be a Data Processor depending on the nature of the arrangement and processing |
| Professional firm receiving information and independently determining how it will use that data for its own purposes | May be a separate Data Fiduciary |
| Office equipment supplier with no role in processing personal data | Generally not a Data Processor |
The distinction is especially important for vendors that receive personal data but exercise some degree of independent decision-making over how it is used. Simply receiving, accessing, or storing personal data does not by itself determine the legal role. The organization needs to examine why the vendor has the data, whose behalf it acts on, and who determines the purpose and means of the processing.
This is where vendor vs Data Processor classification becomes important. A business should assess the actual relationship rather than assign a DPDP role based solely on a vendor category, contract label, or the fact that the vendor has access to personal data.
The role depends on what the vendor actually does with the data, not what the contract calls the vendor.
A clear classification at the start of the vendor lifecycle also helps determine which contractual, security, rights-management, breach-response, and offboarding controls need to apply.
Before Onboarding a Vendor
Start With the Data, Not the Questionnaire
A useful DPDP vendor assessment begins by understanding the actual data flow. A generic questionnaire can collect information, but it does not by itself tell an organization whether a processor relationship creates a compliance gap.
Before onboarding a vendor, establish:
What personal data will the vendor receive?
This may include customer records, employee information, contact details, identity information, uploaded documents, support conversations and processing logs.
Why does the vendor need it?
Connect vendor access to a defined processing purpose. Data access should have a clear business reason that can be documented.
What will the vendor actually do?
Determine whether it will store, analyse, transmit, host, send, modify, delete or otherwise process the data.
Where will the data go?
Record relevant hosting locations, processing locations and external systems involved in the service.
Who can access it?
Understand the people, systems and applications that can access personal data through the vendor relationship.
What happens when the service ends?
Determine how information will be returned, erased or retained where another law requires continued retention.
A documented DPDP readiness assessment helps translate these questions into a clear view of the vendor relationship. This forms the basis for vendor due diligence under DPDP, allowing the organization to evaluate the vendor's security safeguards, breach procedures, access controls, retention and deletion practices, and ability to support applicable data protection obligations.
When the Vendor Suffers a Data Breach
The 72-Hour Rule Is Only Part of the Story
A breach at a vendor can quickly become a reporting and response issue for the Data Fiduciary. Section 8(6) requires the Data Fiduciary to notify the Data Protection Board of India and each affected Data Principal in the prescribed manner when a personal data breach occurs. Rule 7 sets out the timelines and information required for those notifications.
What the Data Fiduciary Must Do
Once the Data Fiduciary becomes aware of a personal data breach:
- Affected Data Principals: They must be informed without delay. The notification must explain the nature, extent and timing of the breach, its likely consequences, measures taken to mitigate the effects, and other prescribed information.
- Data Protection Board of India: An initial intimation must be provided without delay. The Data Fiduciary must then provide updated and detailed information within 72 hours of becoming aware of the breach, unless the Board allows a longer period.
What This Means for Vendor Contracts
The Rules set these notification obligations for the Data Fiduciary. They do not establish a general statutory requirement for every Data Processor to notify the Data Fiduciary within 72 hours.
For this reason, a vendor contract should define an internal breach-notification timeline that gives the Data Fiduciary enough time to understand the incident and meet its own obligations. The agreement should also require the vendor to provide relevant information and cooperate with the investigation and response.
A practical vendor requirement is to report suspected personal data breaches immediately or within a clearly defined internal timeframe. Waiting until the external reporting deadline is approaching can leave too little time to establish what happened, determine whose data was affected, and prepare the required notifications.
Key takeaway : The 72-hour period applies to the Data Fiduciary's detailed notification to the Board. Vendor contracts should provide earlier escalation so the organization has time to respond.
Vendor Contracts Under the DPDP Act
What Does DPDP Actually Require in a Vendor Contract?
Section 8(2) establishes the requirement for a valid contract when a Data Processor is used for covered processing related to offering goods or services to Data Principals. Rule 6(1)(f) also requires an appropriate provision in the Data Fiduciary and Data Processor contract for reasonable security safeguards.
This is the statutory baseline.
What the law expressly requires
A DPDP Data Processor contract should satisfy the applicable requirement for a valid contract, with the security safeguards required by Rule 6 appropriately addressed.
Clauses businesses should consider adding
The following clauses can help the Data Fiduciary operationalize its wider obligations:
- Processing purpose and scope
- Categories of personal data covered
- Permitted uses
- Security requirements
- Access restrictions
- Vendor incident notification time
- Assistance during breach investigation
- Handling of consent withdrawal
- Support for applicable Data Principal requests
- Retention and deletion
- Data return on termination
- Use of further service providers
- Processing locations
- Evidence of security controls
- Audit or assessment rights
- Obligations when the contract ends
The specific clauses will depend on the processing activity, the type of personal data involved, and the controls the Data Fiduciary needs from the processor.
The Act establishes the valid-contract requirement, while Rule 6 specifically addresses the need for an appropriate contractual provision concerning security safeguards. A broader DPDP processor agreement can therefore be designed around the organization's operational needs and its ability to meet other requirements under the Act.
Security Safeguards for Vendor Processing
Rule 6: What Security Controls Need to Extend to Vendors?
Rule 6 directly covers personal data held or controlled by the Data Fiduciary, including processing performed by a Data Processor on its behalf. The minimum safeguards include several measures relevant to third-party processing.
These include:
- Encryption, masking, obfuscation or tokenisation and other appropriate data security measures
- Access controls for computer resources used by the Data Fiduciary or Data Processor
- Logs, monitoring and review to provide visibility into access and help detect, investigate and prevent unauthorized access
- Measures that support continued processing following loss or compromise, such as backups
- Retention of specified logs and personal data for the period required by Rule 6, unless another applicable law requires otherwise
- Appropriate processor-contract provisions covering reasonable security safeguards
- Appropriate technical and organisational measures to ensure effective implementation of the safeguards
For a third-party risk management program under the DPDP Act, these controls should be evaluated in the context of the data and processing activity rather than as a generic security checklist.
Vendor evidence can include security architecture information, access-control documentation, encryption practices, monitoring capabilities, incident-response procedures and relevant assurance reports. Certifications can support an assessment, but they do not by themselves establish compliance with the DPDP Act.
A User Request Cannot Stop at Your Own Database
Data protection responsibilities can extend beyond the organization's own systems when a processor has received the personal data.
Consent withdrawal
Section 6(6) requires the Data Fiduciary, within a reasonable time, to cease the relevant consent-based processing and cause its Data Processors to cease processing as well, unless continued processing without consent is required or authorised under the Act, Rules or another applicable law.
This means consent withdrawal management should account for processor systems, integrations and downstream workflows.
Erasure
Section 8(7) requires the Data Fiduciary, subject to applicable legal retention requirements, to erase personal data when the relevant conditions are met and to cause its Data Processor to erase personal data that was made available to it for processing.
A deletion request therefore needs a mechanism for communicating applicable instructions to processors and recording how those instructions were completed.
Processor visibility
Section 11 gives a Data Principal, in covered circumstances, the right to obtain the identities of Data Fiduciaries and Data Processors with whom personal data has been shared, along with a description of the personal data shared.
Maintaining a reliable vendor and processor register is a practical way to identify where personal data has been shared, support applicable access requests, issue processor instructions and complete deletion.
Retention and Vendor Offboarding
Deleting a Vendor Account Is Not the Same as Deleting the Data
When a vendor relationship ends, the organization needs to determine what happens to the personal data that was processed during the engagement.
Rule 8 specifically addresses retention of personal data, related traffic data and processing logs for certain purposes and periods, including processing carried out by a Data Processor on behalf of a Data Fiduciary. It also includes circumstances where data and logs must be retained for at least one year for specified purposes, subject to applicable legal requirements.
Vendor offboarding should therefore include a clear decision on what data is to be deleted, returned, or retained and for how long. This may include:
- Production systems
- Archived copies
- Processing logs
- Backups
- Exported files
- Test environments
- Service termination records
- Data subject to legal retention requirements
A documented offboarding process helps the organization confirm that the vendor relationship has ended operationally while ensuring that personal data is handled appropriately after processing ends.
Vendor Offboarding Checklist
Before closing the vendor relationship :
- Stop vendor access
- Determine which personal data must be erased
- Identify any legally required retention
- Obtain evidence of data deletion or return where appropriate
- Remove integrations and credentials
- Update the processor inventory
- Document the completed offboarding activities
Foreign and Cloud Vendors
Can a DPDP Data Processor Be Located Outside India?
The DPDP Act does not establish a blanket requirement that all personal data must remain in India.
Section 16 states that the Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to specified countries or territories outside India. It also preserves stricter requirements that may apply under another Indian law.
Rule 15 provides that personal data processed by a Data Fiduciary under the Act may be transferred outside India subject to requirements that the Central Government may specify concerning making that data available to a foreign State or persons or entities under its control or agencies of such a State.
For cloud and overseas vendors, organizations should therefore know:
- Where the vendor hosts and processes personal data
- Which regions and environments are used
- Whether the vendor relies on further providers
- Whether data can be accessed from outside India
- What contractual controls apply to international processing
- Whether any applicable government notification or other Indian law restricts the transfer
The absence of a general localization requirement does not remove the need for visibility into international processing.
Significant Data Fiduciaries and Vendor Risk
Extra Checks If Your Organization Is a Significant Data Fiduciary
Section 10 allows the Central Government to notify a Data Fiduciary or class of Data Fiduciaries as Significant Data Fiduciaries based on factors including the volume and sensitivity of personal data, risks to Data Principal rights and other specified considerations.
For a Significant Data Fiduciary, the Act requires a Data Protection Officer, an independent data auditor and periodic Data Protection Impact Assessments and audits. Rule 13 requires a DPIA and audit once every twelve months from notification or inclusion in a notified class. Organizations managing these responsibilities can also consider DPO support for vendor governance as part of their broader privacy governance framework.
This does not create a separate annual vendor audit requirement.
However, if important processing is performed through cloud providers, SaaS providers or outsourced processors, those relationships should be considered when the organization assesses the risks associated with its processing activities and prepares for its broader DPIA and audit obligations.
What the DPDP Act Does Not Expressly Require
Five Vendor Compliance Claims Businesses Should Treat Carefully
Vendor compliance guidance can become misleading when recommended practices are presented as direct statutory mandates. The following claims should be treated carefully.
Claim 1 : Every third-party vendor is a Data Processor.
Incorrect. Section 2(k) applies to a person who processes personal data on behalf of a Data Fiduciary. Vendors with no relevant personal-data processing role do not automatically fall within that definition.
Claim 2 : DPDP requires an annual audit of every vendor.
Too broad. The annual DPIA and audit requirement in Rule 13 applies to Significant Data Fiduciaries. It is not a general annual audit obligation imposed on every vendor.
Claim 3 : Rule 6 contains a mandatory long-form DPA clause list.
Too broad. Section 8(2) establishes the valid-contract requirement, while Rule 6(1)(f) specifically requires an appropriate contractual provision concerning reasonable security safeguards. The Act and Rules do not provide the long-form checklist of contractual clauses often used in vendor-management programs.
Claim 4 : Every vendor breach only needs to be reported within 72 hours.
Incomplete. Rule 7 requires the Data Fiduciary to notify affected Data Principals without delay and to provide an initial Board intimation without delay, followed by updated detailed information within 72 hours of becoming aware, unless additional time is allowed.
Claim 5 : ISO 27001 or SOC 2 certification automatically makes a vendor DPDP compliant.
The DPDP Act and Rules do not state this. Security certifications can provide useful evidence during vendor risk assessment under the DPDP Act, but they do not replace the Data Fiduciary's legal obligations.
DPDP Vendor Lifecycle
A Practical Vendor Risk Management Process for DPDP
A structured lifecycle can help organizations translate the legal requirements into operational controls without treating every control as an express statutory mandate.
| Stage | What to do |
|---|---|
| 1. Discover | Identify vendors that receive or have access to personal data. |
| 2. Classify | Establish whether the vendor acts as a Data Processor, another Data Fiduciary, or has no relevant role in personal-data processing. |
| 3. Assess | Evaluate the processing purpose, data involved, access, security measures, processing locations, breach procedures, and deletion capabilities. |
| 4. Contract | Formalize the processor relationship through a valid contract and include safeguards needed to support the organization's DPDP obligations. |
| 5. Control Access | Limit vendor access to what is necessary for the agreed service. |
| 6. Monitor Changes | Review material changes, including new processing purposes, data types, processing locations, integrations, or further providers. |
| 7. Handle Rights and Withdrawal | Ensure processor workflows can receive and act on applicable instructions for consent withdrawal and deletion. |
| 8. Prepare for Breaches | Set vendor notification timelines that provide sufficient time to meet the Data Fiduciary's Rule 7 obligations. |
| 9. Offboard | Revoke access, address data deletion and retention, close integrations, and document the outcome. |
This lifecycle forms the foundation of DPDP vendor risk management by connecting data discovery, classification, due diligence, contracting, security and offboarding.
Penalties
What Can Vendor Failures Cost Under the DPDP Act?
Vendor-related failures can have significant consequences for a Data Fiduciary, particularly where they affect required security safeguards or breach notification. The DPDP Act's Schedule sets maximum penalties for specific categories of non-compliance.
For issues relevant to vendor and processor management, the potential penalties include:
| DPDP Act Obligation | Maximum Penalty |
|---|---|
| Failure to take reasonable security safeguards to prevent a personal data breach under Section 8(5) | ₹250 crore |
| Failure to give the Data Protection Board of India or affected Data Principal the required breach notice under Section 8(6) | ₹200 crore |
| Breach of additional obligations relating to children under Section 9 | ₹200 crore |
| Breach of additional obligations applicable to a Significant Data Fiduciary under Section 10 | ₹150 crore |
| Breach of any other provision of the Act or Rules where the residual category applies | ₹50 crore |
These are maximum statutory penalties, not automatic fines for a vendor incident. The Board determines whether a breach is significant and the amount of any monetary penalty based on the factors specified in Section 33.
Vendor Compliance Starts With Knowing Where the Data Goes
A vendor contract is only one part of managing third-party data processing. Businesses also need visibility into which vendors process personal data, why the data is shared, what safeguards are in place, how consent withdrawal and deletion instructions reach processors, how vendor incidents are escalated, and what happens to the data when the relationship ends.
Under the DPDP Act, the central point is straightforward: when a Data Processor handles personal data on behalf of a Data Fiduciary, the Data Fiduciary remains responsible for compliance relating to that processing.
The relevant provisions in this guide are scheduled to take effect on May 13, 2027, based on the 18-month commencement period specified in the November 13, 2025 notification. Businesses should use 2026 to identify their processors, review contracts, assess security controls, map data flows, establish vendor breach procedures and validate deletion and offboarding processes.
FAQs
1. What is vendor risk management under the DPDP Act?
Vendor risk management under DPDP Act refers to the processes an organization uses to identify, classify, assess and control vendors that process or have access to personal data. The Data Fiduciary remains responsible for processing carried out by a Data Processor on its behalf and must use a valid contract for covered processor relationships.
2. Is every vendor considered a Data Processor under the DPDP Act?
No. A Data Processor is a person who processes personal data on behalf of a Data Fiduciary. Vendors that do not process personal data, and third parties that determine purposes and means independently, may fall outside the Data Processor role.
3. Who is responsible when a Data Processor causes a breach?
The Data Fiduciary remains responsible for complying with the DPDP Act and Rules for processing undertaken on its behalf by a Data Processor. This includes the relevant security and breach-notification obligations.
4. Does the DPDP Act require a Data Processing Agreement?
The Act requires a Data Fiduciary using a Data Processor for covered processing related to offering goods or services to Data Principals to do so under a valid contract. Rule 6 also requires an appropriate contractual provision for reasonable security safeguards.
5. What should a DPDP vendor contract include?
At a minimum, the contract should satisfy the valid-contract requirement and address the appropriate security safeguards required by Rule 6. Organizations should also consider clauses covering processing scope, permitted use, access, breach notification, rights requests, consent withdrawal, deletion, retention, subcontracting, processing locations and termination.
6. Does DPDP require a vendor risk assessment before onboarding?
The DPDP Act does not expressly state a universal requirement for a formal vendor risk assessment before every vendor is onboarded. A documented assessment is a practical way to determine whether a proposed processor relationship can support the organization's obligations.
7. How quickly must a vendor-related personal data breach be reported?
The Data Fiduciary must notify affected Data Principals without delay. Rule 7 also requires an initial notification to the Data Protection Board of India without delay, followed by updated and detailed information within 72 hours of becoming aware of the breach, unless additional time is allowed.
8. What happens when a Data Principal withdraws consent and a vendor has the data?
Where consent is the basis for processing, Section 6(6) requires the Data Fiduciary, within a reasonable time, to cease the relevant processing and cause its Data Processors to cease it as well, unless continued processing is otherwise required or authorised by law.
Leave a Comment