Sector wise readiness
SaaS and cloud: the moment a processor becomes a Fiduciary
- Is a SaaS company a Data Processor or a Data Fiduciary?
- Usually a Processor for client data, audited through your clients' contracts rather than directly by the Board, which is lighter than most founders assume. But the moment you use client data for your own purposes, such as analytics or model training, you become a Data Fiduciary for that processing.
- Who this affects
- SaaS, cloud and platform businesses handling customer data.
- What to do about it
- Watch for purpose creep, which nobody signs off and which auditors probe directly, and keep sub processors visible in the contract chain.
A misconception I keep seeing when SaaS and cloud startups read DPDP checklists: they assume the whole Act lands on them the same way it lands on their customers. It does not.
If you process personal data on behalf of your clients, you are usually a Data Processor, not a Data Fiduciary. You are audited through your clients' contracts, not directly by the Board. That is a lighter position than most SaaS founders assume, and a sector map is a superset, not a launch checklist.
What applies from the start, whatever your size
- ✅ Security safeguards (encryption, access control, logging)
- ✅ Breach detection and escalation, fast enough for your client to meet the 72 hour clock
- ✅ Process only under a compliant DPA, with Rule 6 safeguard and breach cooperation clauses
- ✅ Sub-processor visibility, and a clear agreement on who starts the 72 hour clock if a sub-processor detects the breach first
- ✅ Retain logs for at least a year
- ✅ Cross border discipline on where data actually sits
What may not apply to you yet
- ❌ Most Data Principal facing duties (notice, consent, rights handling) sit with your client, the Fiduciary, not you, while you stay a pure processor.
- ❌ SDF obligations. A processor is usually not notified directly.
- ❌ Dedicated DPO, DPIAs, independent audits as standalone duties.
The trap that turns all of that on its head
The moment you use client data for your own purposes, you stop being a processor. Run your own analytics on it, or train a model on it, and for that processing you become a Data Fiduciary, with the full baseline attached.
Purpose creep is silent. No one signs off on it. It just happens when a product team decides client data would make a great training set. Auditors probe exactly this, alongside sub-processors that are invisible to the framework.
The better question
So the real question for SaaS is not "which DPDP duties apply to us?"
It is "are we still only doing what the client instructed, or have we quietly started deciding our own purposes?"
Stay inside client instructions, and you stay a processor. Step outside them, and the law re-classifies you, whatever your contract says. That single line, processor versus Fiduciary, decides most of your obligations. Get it right before you build the feature, not after.
Which obligation do you see SaaS teams over implementing, or missing?