Who is accountable when third parties process personal data under the DPDP Act?

The Data Fiduciary remains accountable even when processors or other third parties handle the data on its behalf. That means the organisation must set security requirements, define breach notification duties, and ensure contracts reflect compliance responsibilities. Accountability cannot be outsourced, because the fiduciary still determines why and how the data is processed.

How the DPDP Act treats accountability when third parties process data

The core rule is that the Data Fiduciary stays accountable for the processing outcome, even when a processor or other third party performs the work. That matters because the legal duty does not shift with outsourcing. The fiduciary still has to choose the processor carefully, set binding instructions, and make sure the processing arrangement preserves the same compliance standard the fiduciary must meet.

Accountability also has to be operational, not just contractual. If a third party handles personal data, the fiduciary needs visibility into what the processor is doing, how security obligations are implemented, and whether the processor can support notification and remediation duties if something goes wrong. The practical test is whether the fiduciary can still demonstrate control over the processing chain.

What third-party processing changes, and what it does not

Third-party involvement changes the execution model, not the responsibility model. A processor may store, transfer, analyse, or otherwise handle personal data on behalf of the fiduciary, but that does not make the processor the party ultimately answerable to the data principal for compliance. The fiduciary remains the decision-maker that determines purpose and means, so it remains the point of accountability.

That distinction is important for governance. The fiduciary should treat vendors, contractors, platforms, and other intermediaries as extensions of its processing environment, not as a liability shield. The arrangement should define scope, permitted use, security controls, retention handling, sub-processing conditions, and breach escalation paths. The more sensitive the data or the broader the sharing, the more the fiduciary needs to prove active oversight rather than passive reliance.

Use a processor only where the fiduciary can document the instructions, boundaries, and permitted processing purpose.
Make sure the contract covers confidentiality, security safeguards, incident reporting, deletion or return, and restrictions on further disclosure.
Review whether the third party introduces cross-border, sub-processing, or concentration risk that affects the fiduciary’s ability to stay compliant.

Why this becomes a real compliance and security issue

The main failure mode is assuming that outsourcing transfers responsibility. It does not. If the third party mishandles data, suffers a breach, or drifts beyond the agreed purpose, the fiduciary still has to answer for the processing relationship and for whether it exercised proper control. That is why vendor due diligence, contract hygiene, and ongoing oversight are part of the compliance obligation, not optional extras.

For a practical comparator, the same accountability pattern appears in privacy law and third-party risk programs more broadly, including the need to maintain security of processing, document governance, and ensure downstream actors do not create uncontrolled exposure. For data-rich environments, the issue is often less about the existence of the processor and more about whether the fiduciary can evidence monitoring, escalation, and corrective action when the processor’s behaviour changes.

GDPR is a useful reference point for the same accountability logic around controllers and processors, especially security and processor governance. EU Digital Operational Resilience Act (DORA) also reflects the same third-party oversight expectation in regulated environments.

Risk and Threat Considerations

Third-party processing creates a control gap when the fiduciary cannot verify how the processor stores, accesses, or shares personal data. The risk is strongest where multiple vendors, sub-processors, or loosely defined support arrangements make it hard to trace responsibility after an incident or compliance failure.

Failure mechanism: The fiduciary loses effective oversight of the processing chain, while the processor’s operational choices create exposure through weak access control, overbroad sharing, inadequate logging, or delayed breach handling.

Impact: Personal data can be exposed or misused, contractual obligations can fail to translate into real safeguards, and the fiduciary may still face regulatory, reputational, and remedial consequences because accountability remains with the party that determined the processing.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC — Cybersecurity Supply Chain Risk Management	Third-party data processing is a supply-chain governance issue.
	PR.DS — Data Security	The question turns on safeguarding personal data during third-party processing.
	PR.AC — Identity Management, Authentication, and Access Control	Third-party access to personal data must be constrained and reviewable.
Recommendation — Apply GV.SC to govern vendor risk, responsibilities, and oversight for outsourced processing. Apply PR.DS to protect personal data across storage, transfer, and processing boundaries. Apply PR.AC to restrict vendor access to only the data and functions they need.
CIS Controls v8	15 — Service Provider Management	Processors and third parties require contractual and operational oversight.
	17 — Incident Response Management	Processors must support breach notification and coordinated response duties.
Recommendation — Use Control 15 to assess, contract, and monitor third parties handling personal data. Use Control 17 to define escalation and reporting expectations for vendor incidents.

Practitioner Guidance

What to verify: Confirm that every third party processing personal data has a defined role, a documented instruction set, and a contract that matches the real processing activity. If the vendor can change sub-processors, storage location, or security tooling without review, treat that as a governance gap rather than a routine procurement issue.

What good looks like: The fiduciary can show who is processing what, for which purpose, under which safeguards, and with which escalation path. When an incident occurs, the organisation should be able to prove not only that the vendor was contracted, but that the fiduciary retained oversight and could drive remediation.

Practitioner takeaway: Outsourcing processing can move operations, but it does not move accountability, so the fiduciary must manage vendors as governed processing dependencies, not as compliance stand-ins.