When a data fiduciary hands personal data to a processor — a cloud host, a payroll provider, an analytics tool — the DPDP Act requires that relationship to be governed by a valid contract. That contract, commonly called a data processing agreement or DPA, is the instrument that carries the fiduciary's obligations down to the parties actually handling the data, and it is a non-negotiable part of dpdp compliance.
A DPA is not boilerplate to be signed and forgotten. It defines what the processor may do, the security it must apply, how it must help with breaches and rights requests, and what happens to the data when the relationship ends.
Because the fiduciary remains accountable for what its processors do, a strong DPA is also a genuine risk-management tool, not merely a compliance formality.
This guide explains why a DPA is mandatory, the clauses it should contain, how to handle sub-processing and breaches, and how to use a template to put compliant agreements in place quickly.
The sections below walk through each part of a sound DPA — scope, security, sub-processing, breach and rights assistance, return and deletion, and audit — so you can put compliant agreements in place with confidence.
Why a DPA is mandatory
The DPDP Act provides that a fiduciary may engage a processor only under a valid contract. This makes the DPA a legal precondition for outsourcing any personal data processing, not an optional nicety.
The rationale is accountability. Because the fiduciary stays responsible to the data principal for what its processors do, the contract is how it imposes the necessary obligations and retains control over the data it is answerable for.
Engaging a processor without a proper DPA leaves the fiduciary exposed: it cannot demonstrate that the data it is responsible for is being handled lawfully, which is exactly what the Board would expect to see.
In short, the DPA is what lets a fiduciary outsource processing without outsourcing responsibility — it keeps the chain of accountability intact even as data moves to third parties.
The practical consequence is that an organisation cannot lawfully spin up a new cloud tool or vendor and start feeding it personal data on a handshake. Until a DPA is in place, that data flow is on shaky ground, which is why mature teams make a signed DPA a gating step in vendor onboarding.
Scope, purpose and duration
A DPA should clearly define the subject matter of the processing, its nature and purpose, the duration of the engagement, and the types of personal data and categories of data principals involved.
This scoping is what binds the processor to act only within defined limits. It prevents scope creep, where a processor gradually uses data for purposes the fiduciary never authorised.
Getting this section precise is the foundation of the whole agreement, because every other obligation is anchored to the defined scope of processing.
A precise scope clause also protects the processor, by making clear what it is and is not authorised to do, which reduces disputes if questions arise later.
Security and confidentiality obligations
The DPA must require the processor to implement appropriate security safeguards — aligned with the encryption, access-control and logging expectations the Act's Rules set — and to keep the personal data confidential.
Because the fiduciary's own security obligation extends to data held by processors, these clauses are how it ensures that obligation is met across its supply chain.
Strong, specific security commitments — rather than vague 'reasonable efforts' language — are what make the DPA genuinely protective.
Tying these obligations to recognised standards, rather than vague assurances, gives both parties a concrete benchmark and makes the processor's compliance easier to verify.
It is worth aligning the security clauses with the same Rule 6 measures you apply internally — encryption or masking, access control with multi-factor authentication, and adequate logging — so that data does not become less protected simply because it has moved to a processor.
Sub-processing controls
A good DPA governs the processor's use of sub-processors: requiring authorisation, flowing down equivalent obligations, and keeping the processor responsible for its sub-processors' conduct.
This matters because data often passes through a chain — a SaaS tool running on a third party's cloud — and the fiduciary needs assurance that obligations persist all the way down.
Many agreements also require the processor to maintain a sub-processor list and to notify the fiduciary of changes, giving visibility into where data actually goes.
Without sub-processing controls, a fiduciary can lose sight of where its data actually resides — precisely the blind spot where breaches and compliance failures tend to occur.
Breach and rights assistance
The DPA should require the processor to assist the fiduciary in meeting its own obligations — notably notifying the fiduciary of breaches promptly so the fiduciary can meet its 72-hour reporting duty, and helping respond to data principal rights requests.
Because the fiduciary's breach clock starts on awareness, a processor that sits on an incident can cause the fiduciary to miss its deadline, so prompt-notification clauses are critical.
Rights-assistance clauses ensure the processor will help locate, correct or delete an individual's data when the fiduciary must honour a request.
In effect, your processors become an extension of your incident-response capability, so their contractual obligations directly determine whether you can meet your own deadlines.
A useful clause specifies a short, defined window within which the processor must notify you of a suspected breach, well inside your own 72-hour duty, so you retain enough time to assess the incident and make your notifications to the Board and affected individuals.
Free resource
Free DPDP Policy Templates
Privacy notice, consent and core DPDP policy documents you can adapt to your business.
Return and deletion of data
A DPA should specify what happens to personal data when the engagement ends: typically that the processor will return or securely delete the data, and delete existing copies, unless law requires retention.
This closes the loop on the data lifecycle, preventing personal data from lingering indefinitely in a former vendor's systems after a relationship ends.
Clear end-of-term provisions also support the fiduciary's own retention and erasure obligations, since data it has had deleted at a processor cannot later be breached.
Specifying the format and timeline for return or deletion avoids the common end-of-contract limbo where data simply sits, unowned and unprotected, in a former vendor's systems.
Audit and accountability
Many DPAs include rights for the fiduciary to audit or obtain assurance about the processor's compliance — through audit rights, certifications, or evidence of controls — reflecting the fiduciary's ongoing accountability.
For widely used processors, certifications such as ISO 27001 or independent audit reports often satisfy this need more efficiently than bespoke audits.
The point is that the fiduciary retains a means to verify, not just assume, that the processor is meeting its obligations.
Relying on a processor's existing certifications for assurance is usually more efficient than bespoke audits, and it is often acceptable to enterprise customers reviewing your supply chain too.
Building a small library of pre-approved DPA templates — one for major cloud vendors, one for smaller tools — lets you onboard new processors quickly without re-litigating the same clauses each time, which keeps compliance from becoming a brake on the business.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.