What Is a Data Processor Under the DPDP Act? A Vendor-Evaluation Checklist for BFSI

Under Section 2 of the DPDP Act, 2023, a “Data Processor” is defined as any person who processes personal data on behalf of a Data Fiduciary, the processor doesn’t determine the purpose or means of processing; it acts on the fiduciary’s instructions. In practice, a processor’s role can look different depending on where in the data flow it sits: some processors collect data directly from users on a fiduciary’s behalf (app-store or aggregator-style intermediaries, for example), while others, cloud storage, payroll, or verification-service providers, work purely from the fiduciary’s downstream instructions. That distinction changes how contractual risk gets allocated between the two parties, but it doesn’t change the statutory processor label itself.

The label isn’t fixed by what a vendor calls itself, though. An entity that starts making its own decisions about why or how personal data is processed, rather than acting solely on a fiduciary’s instructions, risks being treated as a data fiduciary in its own right for that processing, which brings the fuller set of fiduciary obligations (consent management, rights fulfilment, breach liability) rather than the lighter processor position.

The DPDP Act’s Section 8 sets the frame. Section 8(1) states that a data fiduciary “shall, irrespective of any agreement to the contrary or failure of a Data Principal to carry out the duties provided under this Act, be responsible for complying with the provisions of this Act and the rules made thereunder in respect of any processing undertaken by it or on its behalf by a Data Processor.” Section 8(2) adds that a fiduciary “may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for any activity related to offering of goods or services to Data Principals only under a valid contract.”

Read together, those two provisions do two things: a fiduciary can’t contract away its own compliance liability for what a processor does with the data, and the contract between fiduciary and processor is the Act’s own designated mechanism for engaging a processor at all, there’s no lawful path to engaging one outside a valid contract.

That contract mechanism is also where a processor’s obligations actually live. India’s DPDP Act model places comparatively limited direct statutory liability on data processors, accountability runs primarily through the fiduciary, which bears responsibility for compliance and for policing its processors, rather than through independent statutory duties the Act’s own text imposes on the processor. This is a deliberate structural contrast with the EU’s GDPR, where Article 28 processors carry direct statutory obligations of their own, maintaining records, assisting with data protection impact assessments and data-subject requests, and can be fined directly by a regulator. The DPDP Act’s lighter-touch model puts the fiduciary, not the processor, at the center of statutory accountability.

Within that contract-mediated structure, one legal-compliance source, KS&K, converges on five recurring categories of duty a data processor typically carries in practice:

• •Process only on instruction. Processing beyond the fiduciary’s instructions is treated as unlawful and can expose both parties to liability.
• •Take reasonable security measures, with shared exposure if negligence on the processor’s side leads to a breach.
• •Don’t engage sub-processors without the fiduciary’s explicit authorisation.
• •Cooperate with the fiduciary on data-principal rights requests, breach notifications, and audits.
• •Maintain processing records as directed by the fiduciary.

The security duty has a specific statutory anchor. Rule 6 of the DPDP Rules, 2025 sets out the “reasonable security safeguards” a data fiduciary must implement, and Rule 6(f) specifically requires the fiduciary-processor contract to contain a provision requiring the processor to take reasonable security safeguards of its own, extending an equivalent security standard to the processor, but through the mandated contract term, not as an independent duty the Act imposes on the processor directly.

Breach notification works the same way, but the statutory and contractual pieces need to be kept separate. Rule 7 of the DPDP Rules, 2025 governs a fiduciary’s own breach-notification obligations: on becoming aware of a breach, the fiduciary must intimate affected data principals without delay and give the Data Protection Board a detailed report, covering the breach’s nature, extent, timing, and impact, mitigation steps, findings on responsible parties, and recurrence-prevention measures, within 72 hours of becoming aware of it, or such longer period as the Board allows. That 72-hour figure is Rule 7’s fiduciary-to-Board deadline. No primary source in the Act or Rules states a specific numeric deadline for a processor to notify its own fiduciary of a breach. One compliance guide, Consent.in, recommends building a specific processor-to-fiduciary notification window into the DPA itself, variously suggested as “without unreasonable delay,” “promptly,” or a fixed number of hours, precisely because the fiduciary’s own 72-hour clock to the Board starts running regardless of when its processor actually tells it about the breach. That window is a contractual best practice Consent.in recommends, not a number the Act or Rules mandate.

A processor’s relationship with the fiduciary also has an end point. A processor is generally expected to return or delete all personal data on the fiduciary’s instruction, or at the end of the contractual engagement, commonly paired with a requirement that the processor certify the destruction has occurred, since the fiduciary otherwise has no independent way to confirm the data no longer exists on the processor’s systems.

One legal-compliance source, Atlas Systems, describes a consistent clause set a DPDP-compliant DPA should typically contain. ShieldRisk’s vendor-compliance guide and WatchDog Security’s DPA guide describe the same core structure.

Two areas around this checklist deserve a caution rather than a confident rule. The Act’s own text doesn’t address sub-processing at all, it doesn’t require a processor to get the fiduciary’s consent before engaging a sub-processor, or set standard terms for how those relationships must be governed. One legal-commentary source calls this a “regulatory blind spot,” since a fiduciary may not know its processor has passed data further downstream at all unless the contract itself creates that visibility. Because the Act is silent, contractual practice fills the gap unevenly: some DPAs in India lack a clause requiring the processor to get consent before engaging a sub-processor, which the same source describes as permitting delegation of data “without verification of the authenticity of the third party.” The recommended fix, a “flow-down” clause binding sub-processors to equivalent obligations, an up-to-date sub-processor register, and processor liability for its sub-processors’ acts, is good contractual practice, not a statutory requirement.

Cross-border processing carries a similar gap. The DPDP Act permits cross-border transfer by default, subject to any country-specific restrictions the Central Government notifies, but the Act’s text doesn’t specify a standard mechanism for how a processor located outside India must itself comply with Indian data-protection obligations. One legal-commentary source flags this as a live risk: an overseas processor may not actively comply with Indian law absent a contract that explicitly requires it to.

Penalty exposure for a processor specifically is another area to state carefully. Sources disagree on whether the Data Protection Board can penalize a data processor directly, one line of commentary describes the Board’s authority as extending to fiduciaries, processors, and consent managers; another states plainly that processors aren’t directly penalized and the fiduciary remains fully liable for a processor’s violations. Neither has been independently verified against a primary Schedule reproduction naming processors specifically as a penalized category, so that question stays open here. What’s consistently supported is the fiduciary’s own exposure: the up-to-₹250-crore tier for failing to take reasonable security safeguards under Section 8(5), which a fiduciary can’t avoid by pointing to its contract with a processor, per Section 8(1)’s “irrespective of any agreement to the contrary” language.

One compliance-vendor guide, RuleExpert, lays out a recurring evaluation sequencefor assessing any vendor that processes personal data on an institution’s behalf:

1. 1

   Inventory every vendor that processes personal data, and flag which ones handle higher-volume or higher-sensitivity data.

2. 2

   Verify a DPA is actually in place and covers the standard clause set above, not just a generic services contract.

3. 3

   Map what data the vendor touches: why, where it’s stored, for how long, and who else (including sub-processors) can access it.

4. 4

   Request evidence of the vendor’s security posture, a SOC 2 Type II report or ISO/IEC 27001 certification, for example, while treating a certification as supporting evidence rather than automatic proof of DPDP-specific compliance.

5. 5

   Confirm the vendor’s data-deletion or return process, and require certification of destruction at contract termination.

6. 6

   Set clear rights-fulfilment timelines the vendor must meet when the institution needs to service an access, correction, or erasure request.

7. 7

   Treat vendor DPDP compliance as ongoing, periodically reassessed, rather than a one-time onboarding check.

For a BFSI institution specifically, this DPDP-level review sits alongside a separate outsourcing regime from RBI that predates and layers on top of it. The Reserve Bank of India (Commercial Banks, Managing Risks in Outsourcing) Directions, 2025 (RBI/DOR/2025-26/171, dated 28 November 2025) require banks to perform risk-based due diligence on service providers across “qualitative, quantitative, financial, operational, legal, and reputational factors,” restrict a service provider’s or its staff’s access to customer information to a “need to know” basis, and prohibit commingling of customer data across a vendor’s other clients. A parallel instrument, the Reserve Bank of India (Non-Banking Financial Companies, Managing Risks in Outsourcing) Directions, 2025 (no separate instrument number is available in the sourcing for this piece), also dated 28 November 2025, applies the equivalent framework to NBFCs: risk-based, continuous due diligence of IT service providers, tracking of service-level performance and incident response, and unrestricted access to relevant vendor data and premises for the NBFC, its auditors, and RBI itself.

Both 2025 RBI outsourcing Directions require existing IT outsourcing agreements to be brought into compliance either at contract renewal or by 10 April 2026, whichever comes first, and both extend the regulated entity’s oversight and inspection rights down to material sub-contractors of the primary service provider, not just the primary vendor.

Read together, the claims above point to a specific gap a BFSI institution’s procurement process can miss. DPDP Act processor obligations, the contract-mediated duties on instruction-following, security, breach cooperation, and data return covered above, and RBI’s sector-specific outsourcing due-diligence and access-rights requirements are two distinct, overlapping compliance layers that a single vendor contract needs to satisfy at the same time. A DPA that covers the standard DPDP clause set without also meeting RBI’s due-diligence, access-rights, and sub-contractor-oversight requirements would leave a regulated BFSI institution short on the RBI side even if it were fully DPDP-compliant on paper.

The practical implication is that “does this vendor have a DPA” is not the same question as “is this vendor contract complete” for a bank or NBFC. Both 2025 RBI Outsourcing Directions require existing agreements to be brought into line by 10 April 2026 or contract renewal, whichever comes first, which suggests institutions currently relying on older outsourcing agreements have a fixed window to run both checklists (the DPDP vendor-evaluation sequence above and RBI’s due-diligence/access-rights requirements) against every vendor contract that touches customer personal data, rather than treating the two as separate projects on separate timelines.

How a vendor labels itself internally, as a processor or otherwise, for a given engagement, doesn’t determine what its contract with a BFSI institution needs to contain; that’s set by the obligation pattern described above, not by the vendor’s own classification. This piece describes the general obligation pattern the Act creates for a data processor and how a BFSI institution should evaluate any vendor against it; it does not make a determination about how any specific vendor, including a RegTech, KYC, cloud, or analytics provider, is classified for a given engagement. That determination depends on the specific facts of each engagement and the terms of the underlying contract.