The Security Gap Nobody Talks About
Every conversation about DPDPA compliance eventually reaches Rule 6, the security safeguards obligation. Most legal teams read it, note that the Data Fiduciary (DF) must implement appropriate technical and organisational measures, and move on to the next checklist item.
Here's what they miss: Rule 6 requires you to maintain security safeguards over personal data you hold. But the moment that data travels to an analytics vendor, a payroll processor, a marketing automation platform, or a cloud infrastructure provider, you are no longer the one controlling those safeguards. The vendor is. And if that vendor's controls are weaker, your own compliance posture is structurally undermined, regardless of what you've implemented internally.
The mechanism that closes this gap is the processor contract. Under the DPDPA framework, Section 8(2) requires Data Fiduciaries to ensure that any Data Processor they engage provides sufficient guarantees about their security practices. Rule 6 defines what "sufficient" means. The practical consequence is that whatever your own safeguards require, you must contractually bind your processors to the same standard. In our experience, fewer than one in five vendor contracts we review actually does this.
What a Rule 6-Compliant Processor Contract Must Include
The minimum safeguards required under Rule 6, translated into contract obligations, come down to five specific requirements that must appear in any agreement where a vendor processes personal data on your behalf.
Encryption in transit and at rest. The contract must specify that all personal data is encrypted during transmission (TLS 1.2 or higher is the current baseline) and when stored. "Reasonable security" language does not satisfy this, the obligation must be explicit.
Need-to-know access controls. Access to personal data at the processor's end must be limited to staff who require it for the specific processing purpose described in the agreement. The contract should require documented access policies and periodic access reviews.
Access logging. The processor must maintain logs of who accessed personal data, when, and for what purpose. This is non-negotiable under the accountability expectations that flow from Section 8(2). Without logs, neither party can reconstruct what happened in a breach scenario.
Periodic vulnerability assessments. The processor must conduct regular penetration testing and vulnerability scans against systems that store or process your personal data. Annually is a minimum; quarterly is better for processors handling sensitive categories.
Breach notification within a defined window. This is where most vendor MSAs fail completely. The DPDPA requires you to notify the Data Protection Board of India within 72 hours of becoming aware of a breach (Section 8(6)). To meet that window, you need your processor to notify you considerably faster. Our view is that processor contracts should require notification to the DF within 24 hours of the processor becoming aware of any actual or suspected breach. A "we'll tell you in 72 hours" clause from your vendor leaves you with no margin at all.
The Sub-Processor Problem
Here is where the liability chain gets genuinely complicated, and where most compliance programmes have a blind spot.
Your analytics vendor runs on AWS. Your payroll SaaS uses a third-party background verification API. Your marketing platform routes data through a CDN you've never heard of. Under DPDPA, the chain of accountability for that personal data runs back to you, the Data Fiduciary. Section 8(1) makes the DF responsible for the acts and omissions of its processors. A sub-processor's infrastructure breach is, in regulatory terms, your problem.
Your processor contract must do two things about this. First, it must prohibit sub-processing without your prior written approval. Second, it must require that any approved sub-processor is bound by the same safeguard obligations as the primary processor. A clause that simply says "vendor may use sub-processors" is not DPDPA-compliant. The obligation must flow down the chain.
The "Reasonable Security" Problem in Standard MSAs
Walk through any major SaaS vendor's standard terms and you'll find language like "industry-standard security practices" or "commercially reasonable measures." We've seen this in contracts from large enterprise vendors who absolutely should know better.
These formulations are not DPDPA-compliant. They are not specific, they are not auditable, and in a dispute they give the processor maximum room to argue that whatever they did was "reasonable." Rule 6 requires defined safeguards, not a reasonableness standard.
The practical fix is a Data Processor Addendum, a short, standalone document that can be attached to any existing vendor agreement. It should explicitly state the encryption requirements, the access control obligations, the breach notification window, the deletion obligation on contract termination (Rule 8(7)), and the sub-processor restriction. When a vendor pushes back on signing it, that is useful information.
The Audit Right Clause
Signing a DPA addendum does not mean the vendor implements the controls. We'd argue the most underused clause in processor contracts is the right to audit, the right to request evidence of compliance at reasonable intervals. This means penetration test reports, access log samples, certifications (ISO 27001, SOC 2), or answers to a standardised security questionnaire.
Vendors who genuinely maintain strong controls typically have no objection to sharing this evidence. Vendors who resist audit rights consistently are telling you something about what the evidence would show.
The Bottom Line
Rule 6 does not end at your perimeter, your security obligations extend contractually to every vendor who processes personal data on your behalf. Every standard MSA that references "reasonable security" instead of specific, auditable controls is a compliance gap with your name on it.
Download the DPDPA Compliance Guidebook at truconsent.io/guide for a ready-to-use Data Processor Addendum template and a vendor security questionnaire you can deploy immediately.