DPDP Act20 May 2026 7 min read

DPDP Act Data Processor Requirements: What You Must Do

What the DPDP Act requires of Data Processors — contractual obligations, security safeguards, sub-processing rules, and how to manage processor relationships as a Data Fiduciary.

Key Takeaways

Data Processors under the DPDP Act have almost no direct statutory obligations — their obligations flow from the Data Fiduciary via contract.
Every Data Fiduciary must have a written Data Processing Agreement (DPA) with each processor covering purpose, security, and breach notification.
Data Fiduciaries are accountable for their processors' compliance failures — selecting reliable processors and monitoring them is an obligation.
Sub-processing (a processor engaging another processor) must be authorised by the Data Fiduciary.
At contract end, processors must return or delete all personal data as directed by the Data Fiduciary.

In this guide

Who Is a Data Processor Under the DPDP Act
What the Act Directly Requires of Processors
Data Processing Agreement Requirements
Security Obligations in Processor Agreements
Sub-Processing: Engaging Further Processors
Data Fiduciary Accountability for Processor Failures
Auditing Your Processors: Due Diligence Requirements

Who Is a Data Processor Under the DPDP Act

Section 2(k) defines a "Data Processor" as any person who processes personal data on behalf of a Data Fiduciary. The defining characteristic is "on behalf of" — the processor acts under the instructions of the fiduciary and does not determine the purpose or means of processing. Determining purpose or means makes you a Data Fiduciary, not a Processor.

Common examples of Data Processors in the Indian B2B context: cloud infrastructure providers (AWS, Azure, GCP) when used to host applications that process customer data; payroll service providers processing employee data; CRM platforms (Salesforce, Zoho) where customer records are stored; email service providers (Mailchimp, SendGrid) used to send communications to your users; and analytics vendors.

The same entity can be both a Data Processor and a Data Fiduciary for different data sets. AWS processes your customer's data as a Processor when it runs your application, but is a Data Fiduciary for its own account holder data (your billing information, your employee IAM accounts). The legal analysis is data-set-specific, not entity-level.

What the Act Directly Requires of Processors

The DPDP Act imposes almost no direct statutory obligations on Data Processors. Unlike GDPR (which directly obligates data processors under Articles 28-29, including data subject rights fulfilment and breach notification), the DPDP Act takes a contractual model: processor obligations flow from the Data Fiduciary through the Data Processing Agreement.

The one implicit statutory obligation on Processors is that they must process personal data only in accordance with the DPA with the Data Fiduciary. Section 8(2) states that the Data Fiduciary must ensure this by contract. A Processor who processes data outside the scope of the DPA (e.g., using customer data for its own commercial purposes) could face liability under the Act and potentially under contract and tort.

This structure means that if you are primarily a Data Processor (a B2B SaaS company, a cloud service provider, a payroll bureau), your DPDP Act exposure is primarily contractual and reputational, not direct regulatory. However, your customer Data Fiduciaries will demand DPA terms — and your ability to sign strong DPAs will be a competitive requirement.

Data Processing Agreement Requirements

Section 8(2) requires Data Fiduciaries to have a valid contract with each Data Processor governing the processing. A compliant DPA should address: the subject matter, duration, and nature of the processing; the types of personal data involved; the categories of Data Principals; the instructions of the Data Fiduciary regarding processing; the security measures the Processor must implement; breach notification obligations; and data return or deletion at contract end.

Standard SaaS terms of service are usually insufficient. Most vendor ToS are designed to protect the vendor, not to allocate DPDP Act obligations correctly. Review the ToS of every vendor that processes personal data on your behalf and seek DPA annexures where the ToS is inadequate.

DPA negotiation with large vendors can be challenging — hyperscale cloud providers and global SaaS companies have standard DPA templates. Review these carefully against DPDP Act requirements. For smaller vendors who do not offer a standard DPA, use your own DPA template and require them to sign it as a condition of engagement.

Security Obligations in Processor Agreements

Your DPA must require the Processor to implement security safeguards equivalent to those you implement as a Data Fiduciary. At minimum, the security provisions should require: encryption of personal data at rest and in transit; access controls limiting access to authorised personnel; security monitoring and incident detection; and cooperation with your security audits or requests for security evidence (such as SOC 2 reports or ISO 27001 certificates).

Require Processors to notify you of personal data breaches promptly — within a timeframe that allows you to meet your 72-hour Board notification obligation. If your processor takes 48 hours to notify you and you then have only 24 hours left, you will be unable to meet the deadline. Best practice is to require processor notification within 24 hours of the processor becoming aware.

Require Processors to cooperate in breach investigations and to provide all information needed for your Board notification. Processors should not restrict your ability to notify the Board about a breach caused by their systems — any such restriction in a ToS is a red flag.

Sub-Processing: Engaging Further Processors

Sub-processing occurs when your Data Processor engages another entity to carry out processing on your behalf — for example, your cloud provider using a sub-contractor for data centre operations, or your CRM vendor using a hosting sub-processor. The DPDP Act does not explicitly address sub-processing but your DPA should require the Processor to obtain your authorisation before engaging sub-processors.

Two models exist: prior written authorisation for each sub-processor (most control for the Data Fiduciary); or general authorisation with notification and right to object (more practical for large vendors with many sub-processors). Global SaaS vendors typically use the general authorisation model and maintain a published list of sub-processors.

Require your Processors to ensure that sub-processor agreements impose equivalent security obligations. Your exposure as a Data Fiduciary extends through the chain: a breach at a sub-processor is your notifiable breach. The DPA chain must ensure that breach notifications flow back to you promptly at every level.

Data Fiduciary Accountability for Processor Failures

The DPDP Act places ultimate accountability for processor compliance on the Data Fiduciary. If your processor has a breach because they failed to implement adequate security, you are the party that faces the Board penalty for inadequate security safeguards (up to ₹250 crore). You may have contractual recourse against the processor, but the regulatory exposure is yours.

This accountability structure makes vendor selection and monitoring a compliance obligation, not just a commercial judgment. Due diligence before engaging a processor should include: reviewing their security certifications (SOC 2 Type II, ISO 27001); reviewing their DPA terms; understanding their breach notification history; and assessing their financial viability (an insolvent processor cannot pay contractual penalties).

Ongoing monitoring is also required. Periodic review of your processors' security posture — at minimum annually, or after any significant breach news in the industry — is part of your obligations under Section 8(2). Platforms like AuditPath allow you to track processor compliance status alongside your own internal controls.

Auditing Your Processors: Due Diligence Requirements

Before engaging a new processor for any significant personal data processing, conduct due diligence: request evidence of security certifications; review the proposed DPA for adequacy; understand the data residency (is data stored in India or overseas?); and assess the processor's breach notification procedures.

For existing processors, schedule periodic reviews — annually at minimum. Request updated security certifications (SOC 2 reports are typically annual; ISO 27001 certificates are triennial with annual surveillance). Review any published security bulletins or breach disclosures from the processor.

Build a vendor register that tracks, for each processor: the data categories they process; whether there is a current DPA in place; the DPA expiry or review date; their latest security certification; and any breach incidents. This register is evidence of your Section 8(2) compliance and will be a key document in any Board investigation.

Frequently Asked Questions

As a SaaS company, our customers upload their users' data. Are we a Data Processor?

Yes, for that uploaded data — you process it on behalf of your customer (the Data Fiduciary) who has determined the purpose and means. You should offer a standard DPA to customers, as they are legally required to have one with you. You remain a Data Fiduciary for your own account holder data (customer admin accounts, billing information).

Can we use a subcontractor (sub-processor) without telling the Data Fiduciary?

No. Your DPA should require you to notify the Data Fiduciary before engaging sub-processors and obtain authorisation. Processing through unauthorised sub-processors is a breach of your contractual obligation to the Data Fiduciary and may expose the Fiduciary to regulatory risk if the sub-processor causes a breach.

What is the minimum content a DPA must contain?

A minimum compliant DPA should include: the processing subject matter and duration; the nature and purpose of processing; the types of personal data and Data Principal categories; the Data Fiduciary's instructions; security obligations; breach notification requirements (timeline and content); data return or deletion obligations at contract end; and audit rights for the Data Fiduciary.

We use Google Analytics — do we need a DPA with Google?

Yes. Google Analytics processes personal data (IP addresses, device IDs, usage data) on your behalf. Google offers a standard Data Processing Amendment to its Terms of Service. You should sign this amendment. Note that depending on your configuration, Google may also be a joint controller for some Analytics processing — review Google's current terms carefully.

What happens if our processor refuses to sign a DPA?

A processor who refuses a DPA puts you in breach of your Section 8(2) obligation. You must either: negotiate DPA terms (many vendors have standard DPA templates); use an alternative processor that will sign a DPA; or cease using the processor for personal data processing. "Our vendor won't sign a DPA" is not a defence before the Data Protection Board.