Rule 6 requires you to maintain security safeguards over personal data — but once that data reaches a vendor, they control those safeguards, not you. The contract is the only lever you have left.
July 2026 · 5 min read
Every DPDPA compliance conversation eventually reaches Rule 6, the security safeguards obligation. Most legal teams read it, confirm that "technical and organisational measures" are in place, and check the box.
Here's the part that gets skipped: Rule 6 requires you to maintain safeguards over the personal data you hold. But the instant that data moves to an analytics vendor, a payroll processor, a marketing platform, or a cloud provider, you're no longer the one controlling those safeguards — the vendor is. If their controls are weaker than yours, your own compliance posture is compromised structurally, no matter how well you've built your own side.
The mechanism that closes this gap is the contract. Section 8(2) of the DPDPA requires Data Fiduciaries to ensure any processor they engage gives sufficient guarantees on security practice, and Rule 6 defines what "sufficient" actually means. In practice, whatever your own safeguards require, you have to contractually bind your processors to the same bar. In our review experience, fewer than one in five vendor contracts actually does this.
Translated into contractual language, Rule 6's minimum safeguards come down to five specific obligations that need to appear explicitly in any agreement where a vendor touches personal data on your behalf.
The contract has to state, specifically, that personal data is encrypted both during transmission (TLS 1.2 or higher as the current baseline) and in storage. "Reasonable security" language on its own doesn't meet this bar — the obligation needs to be explicit and named.
Access at the processor's end has to be restricted to staff who genuinely need it for the specific purpose described in the agreement, with documented access policies and periodic reviews required by contract, not left to the vendor's discretion.
The processor has to maintain logs of who accessed personal data, when, and why. This isn't optional under the accountability chain Section 8(2) creates — without logs on both sides, nobody can reconstruct what happened if something goes wrong.
The processor needs to run regular penetration testing and vulnerability scans against any system that stores or processes your data. Annual is a floor; quarterly is the better standard for anyone handling sensitive categories.
This is where most vendor MSAs fail outright. You have 72 hours to notify the Data Protection Board under Section 8(6) once you become aware of a breach. To actually hit that window, your processor needs to notify you considerably faster than that. We recommend requiring notification within 24 hours of the processor becoming aware of any actual or suspected breach — a standard "we'll tell you within 72 hours" clause leaves you with zero margin to act.
This is where the liability chain gets genuinely complicated, and where most programmes have a blind spot they haven't noticed yet.
Your analytics vendor runs on AWS. Your payroll platform calls a third-party background-verification API. Your marketing tool routes data through a CDN you've never heard of. Under DPDPA, accountability for that data traces all the way back to you — Section 8(1) makes the Fiduciary responsible for its processors' acts and omissions. A sub-processor's infrastructure breach is, in regulatory terms, still your problem.
Your contract needs to do two things about this: prohibit sub-processing without your prior written approval, and require that any approved sub-processor is bound by the same safeguard obligations as the primary processor. A clause that just says "vendor may use sub-processors" doesn't satisfy DPDPA — the obligation has to flow all the way down the chain.
Look through most major SaaS vendors' standard terms and you'll find phrases like "industry-standard security practices" or "commercially reasonable measures" — including from large enterprise vendors who should know better.
None of that language is DPDPA-compliant. It isn't specific, it isn't auditable, and in a dispute it gives the processor maximum room to argue that whatever they did counted as "reasonable." Rule 6 asks for defined safeguards, not a reasonableness test.
The practical fix is a standalone Data Processor Addendum you can attach to any existing agreement — stating the encryption requirement, access-control obligation, breach-notification window, deletion obligation on termination (Rule 8(7)), and the sub-processor restriction explicitly. If a vendor pushes back on signing it, that reaction tells you something worth knowing.
Signing an addendum doesn't confirm the vendor actually implements any of it. The most underused clause in processor contracts is the audit right — the ability to request evidence of compliance at reasonable intervals: penetration test reports, access log samples, certifications like ISO 27001 or SOC 2, or a completed security questionnaire.
Vendors with genuinely strong controls rarely object to sharing this. Vendors who consistently resist audit rights are telling you what the evidence would show.
Rule 6 doesn't stop at your own perimeter — it extends contractually to every vendor touching personal data on your behalf. Every MSA that leans on "reasonable security" instead of specific, auditable controls is a compliance gap sitting with your name on it.
Our vendor agreement annexures service builds these five requirements directly into your processor contracts, rather than leaving them to a generic template.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation