DPDP for Legal Counsel: Reviewing Vendor Contracts for Section 8(2) Compliance
Section 8(2) contract requirements are easy to state and surprisingly easy to miss in practice. A clause-by-clause review approach for legal teams.
What Section 8(2) is actually asking for
Section 8(2) requires a Data Fiduciary to have a valid contract in place with any Data Processor engaged to process personal data on its behalf, before that processing begins. The Act doesn't prescribe a rigid clause list, but the underlying purpose is clear: the Fiduciary remains accountable for what happens to the data, so the contract needs to give it real, enforceable control over the processor's conduct — not just a general services agreement with a data-protection paragraph appended.
In practice, this means legal teams reviewing vendor paper should stop treating 'data protection clause included' as a checkbox and instead verify the clause actually does the job: defines the processing purpose, sets security expectations, and gives the Fiduciary levers to act if the processor falls short.
The core terms to look for
Purpose limitation: does the contract restrict the processor to processing personal data only for the purposes you've specified, rather than a broad 'as needed to provide the services' formulation that leaves room for the processor's own commercial use of the data.
Security and breach obligations: does the processor commit to safeguards at least as strong as your own, and to prompt notification if something goes wrong on their end — you still owe your own Data Principals and the Board a timely intimation under Section 8(6), and you can't do that if the processor sits on an incident.
Sub-processing: does the contract require your consent or at least notice before the processor engages its own sub-processors, so you're not discovering a fourth party has your customer data only after an incident.
Erasure and return of data: does the contract specify what happens to personal data at the end of the relationship — deletion, return, or continued retention only where you've separately justified it — consistent with your own Section 8(7) obligations.
Withdrawal propagation and audit rights
Section 6 requires that when a Data Principal withdraws consent, that withdrawal has consequences for processors too. Your vendor contracts should include a mechanism for you to instruct the processor to stop processing or delete specific records — a contract silent on this leaves you unable to actually comply when a withdrawal or erasure request comes in.
Where the vendor relationship is significant (large-scale processing, sensitive categories, offshore infrastructure), consider audit or inspection rights, even if lightweight — the ability to request evidence of security controls, rather than relying entirely on a vendor's self-certification.
A pragmatic review workflow
Rather than reviewing every vendor contract from scratch, build a short internal checklist covering the terms above and triage vendors by risk — a payment processor or cloud host warrants a full review; a low-risk SaaS tool touching no personal data may not need the same depth.
Keep a simple register of which vendor contracts have been reviewed and against what version of your checklist, so renewals and amendments get flagged for re-review rather than auto-renewing unchecked.
Where to go next
Use the Vendor Assessment to standardise this review across all vendors, and the Evidence Tracker to keep a record of which contracts have been checked and when.