The DPDP Act is sector-neutral by design. Obligations attach to the processing of digital personal data, so a hospital, a bank and a bookshop owe substantially the same duties, and most sector guides are one checklist with a different logo.
SaaS is a real exception, for a structural reason rather than a regulatory one: it is the sector where a single company is most reliably both roles in the same system. Almost every other industry is predominantly a Data Fiduciary. A SaaS company is both, at the same time, and often cannot tell you which table is which.
That is not a compliance nicety. It determines who the individual has rights against, who must give notice, and who answers to the Board.
| Data in your platform | Your role | Who the individual has rights against |
|---|---|---|
| Your customer's end-user records, loaded or synced by them | Data Processor | Your customer |
| Your customer's employees as platform users, provisioned by them | Data Processor, usually | Your customer |
| Your own signup, account and admin users | Data Fiduciary | You |
| Billing contacts and payment records | Data Fiduciary | You |
| Website visitors, marketing leads, trial signups | Data Fiduciary | You |
| Support tickets your customer's staff raise with you | Data Fiduciary for the ticket, Processor for data inside it | Both, by layer |
| Product telemetry and usage analytics | Depends entirely on whether it identifies individuals and who decided the purpose | — |
The last two rows are where most organisations are wrong. A support ticket contains your relationship with the person who raised it — that is yours as Fiduciary — and may contain end-user personal data pasted into the body, which remains your customer's. Telemetry is Fiduciary data if you decided to collect it for your own product decisions, even where it originates in a customer tenancy.
The working test: if you would be the one deciding to start a new use of the data, you are the Fiduciary for it.
Two sub-sections govern the processor relationship, and read together they are demanding.
Section 8(1). The Data Fiduciary is responsible for compliance in respect of processing undertaken by it or on its behalf by a Data Processor, notwithstanding any agreement to the contrary.
Section 8(2). A Data Fiduciary may engage a Data Processor only under a valid contract.
For a SaaS company this cuts both ways, and the second direction is the one that gets missed.
Downwards, as a Processor: your customers are accountable for your failures. Expect their procurement to test this. A Data Processing Agreement is not a nice-to-have in Indian enterprise sales from 2027; it is the document without which the deal does not close.
Upwards, as a Fiduciary: your own sub-processor chain — hosting, transactional email, error monitoring, analytics, payments — sits under your accountability for your own Fiduciary data, and under your customer's accountability, through you, for theirs. Both require a contract, and both require you to know where the data actually goes.
Rule 8(3) requires retention of personal data, associated traffic data and processing logs for a minimum of one year from the date of processing — expressly including processing undertaken on the Fiduciary's behalf by a Data Processor. The Rules illustrate the point with a company engaging a cloud service provider to host customer records: the Fiduciary must ensure the provider also retains the data and logs for at least a year.
For a SaaS platform this produces a requirement that is easy to state and awkward to build: your deletion behaviour must be capable of expressing "erase this, retain that," per tenant, per purpose. A tenant-level hard delete that purges everything satisfies your customer's erasure instruction and breaches their retention obligation simultaneously. → Retention & Erasure
Section 17(1)(d) disapplies Chapter II (except sections 8(1) and 8(5)), Chapter III and section 16 where personal data of Data Principals not within the territory of India is processed pursuant to a contract entered into with a person outside India by a person based in India.
This is the offshore services exemption, and it is the provision most relevant to Indian IT services, BPO and GCC operations. Read it precisely, because three conditions all have to hold:
And note what survives the exemption. Section 8(1) accountability and section 8(5), the reasonable security safeguards obligation, continue to apply — which is the head carrying the ₹250 crore maximum. The exemption relieves you of notice, consent and rights machinery for that offshore work. It does not relieve you of securing the data.
A practical consequence: an Indian IT services company with a mixed book needs to segregate offshore contract work from domestic work at the system level, because the two are subject to materially different obligations. A single commingled environment forfeits the exemption's benefit in practice, because you cannot demonstrate which data it applies to.
Consiva runs the consent, rights and records layer for your own Fiduciary data, and gives your customers tenant-scoped consent and rights tooling inside your product where you resell or embed it. The role classification in step 1 is yours to determine; the platform holds the determination and applies it consistently.
Consiva itself sits in exactly this dual position, which is why our own privacy notice separates the two roles explicitly. → Privacy
Start free — 1 domain, 1,000 cookie consents and 50 form consents a month, no card. Data Discovery across SQL Server, MySQL and PostgreSQL — the tooling for the dual-role separation above — is on Enterprise. → Pricing
Usually both. You are a Data Processor for personal data your customers load into the platform, and a Data Fiduciary for your own users' account, billing, support and marketing data. The roles are determined per data set by who chose the purpose, not per company.
Yes. The Act governs digital personal data about identifiable individuals and draws no distinction between personal and professional context. Your customers' employees, your billing contacts and your leads are all Data Principals.
Section 17(1)(d) disapplies much of the Act where personal data of Data Principals outside India is processed under a contract with a person outside India by a person based in India. But sections 8(1) and 8(5) — accountability and reasonable security safeguards — continue to apply.
Section 8(2) permits a Data Fiduciary to engage a Data Processor only under a valid contract, so your customers will require one from you. From 2027 expect it to be a gating item in Indian enterprise procurement.
For your own Fiduciary data, yes, directly. For your customers' data, your customer carries accountability under section 8(1) — through you — which is why they will ask for your subprocessor list and their contract will constrain your right to change it.
Verified against the Gazette of India on 17 August 2026. Sources: Digital Personal Data Protection Act, 2023, ss. 8, 12, 17(1)(d); DPDP Rules, 2025, Rule 8(3) and its illustrations. Reference material about the law, not legal advice — see /disclaimer.
Consiva.ai covers every obligation above with pre-configured workflows, templates, and automated jobs — purpose-built for India's data protection law.
Start Free — No Credit Card →