Two Roles, One Codebase.
A SaaS company is a Data Processor for its customers' data and a Data Fiduciary for its own users' data - usually in the same system, often in the same table. The Act treats those two positions very differently.
Covers: B2B software, IT services, BPO, cloud platforms, developer tools.
Why this sector is treated differently
The Act defines a Data Processor as any person who processes personal data on behalf of a Data Fiduciary. When your customer decides what happens to their end-users' data and you execute it, that is you. But you also run signup, billing, support and your own product analytics, and for those you determine the purpose and means yourself - which makes you a Data Fiduciary. Both are true simultaneously, and the obligations differ sharply, so the first task is knowing which data sits in which role.
The Act's structure of processor liability is worth reading closely, because it is not what a GDPR-trained team expects. Section 8(1) makes the Data Fiduciary responsible for complying with the Act in respect of any processing undertaken by it or on its behalf by a Data Processor - irrespective of any agreement to the contrary. The customer cannot contract that responsibility away to you. Section 8(2) then requires that a Data Fiduciary may involve a Data Processor for any activity related to offering goods or services only under a valid contract.
The Act does not prescribe that contract's contents the way the GDPR's Article 28 does. That sounds like less work and is often more, because there is no statutory template to fall back on: what the contract must achieve is whatever lets your customer discharge their own section 8 duties through you. In practice this makes your Data Processing Addendum a commercial document as much as a legal one, and it becomes a procurement gate for enterprise deals.
One provision is specifically useful to offshore IT services. 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 outside India is processed under a contract with a person outside India by a person based in India. That is the export services model, and the Act deliberately declines to regulate it beyond accountability and security.
What you actually process
One row per activity, not per data type. Lawful basis and erasure attach to a purpose, so the same phone number can sit in three rows below with three different answers.
| Activity | Lawful basis | When it must go |
|---|---|---|
| Process a customer's dataWhatever the customer stores in your product | § 8(2)A Data Fiduciary may involve a Processor only under a valid contract. The Act does not enumerate its clauses the way the GDPR does, so the contract has to be built around what your customer must be able to prove. | § 8(7)Erase on the Fiduciary's instruction, including copies held by sub-processors and in backups. |
| Run your own productAccount holder identity, Billing records, Support tickets, Product analytics | § 6Here you determine purpose and means, so you are the Data Fiduciary with the full set of obligations, including notice and consent. | § 8(7)Billing records may be required by tax law; those periods sit outside this Act and should be confirmed against those statutes. |
| Honour a cessation instructionThe affected end-user's records, everywhere | § 6(6)On withdrawal the Fiduciary shall cease and cause its Processors to cease within a reasonable time. Reasonable is measured against your architecture, not your intentions. | § 8(7)(b)The Fiduciary must cause its Processor to erase data made available to it. That is you. |
| Serve offshore clientsThe offshore client's end-user data | § 17(1)(d)Chapter II except sections 8(1) and 8(5), Chapter III and section 16 do not apply where personal data of Data Principals outside India is processed under a contract with a person outside India, by a person based in India. | § 8(5)Responsibility and reasonable security safeguards survive the exemption. |
The data flow, and where it breaks
Each lane follows one activity through the actors and systems that touch the data. The failure mode sits on the hop where it happens, rather than in a list somewhere else on the page.
Process a customer's data
Do what your customer instructs, on their end-users' data
- Customer tenantHolds the customer's end-user data§ 8(1)Fails when: Your customer believing liability transferred to you, which section 8(1) prevents
- Your servicesProcess on instruction§ 8(2)Fails when: Operating with no processing contract, putting the customer in breach by using you
- Sub-processorsHosting, email, search, support tooling§ 8(2)Fails when: Sub-processors added without notice, so the customer cannot discharge their own duty
- BackupsRetain copies§ 8(7)Fails when: Deletion honoured in the primary store while backups quietly retain everything
Run your own product
Sign up, bill and improve the service
- SignupCollects the account holder's details§ 5Fails when: The same notice used for your users and your customers' end-users, which are different relationships
- BillingHolds payment records§ 8(7)Fails when: Retained indefinitely on a tax argument that was never checked
- Product analyticsObserves how the product is used§ 6Fails when: End-user data from customer tenants flowing into your own analytics, where you are not the Processor any more
Honour a cessation instruction
Stop processing when your customer's user withdraws consent
- Customer API callSignals withdrawal or erasure§ 6(6)Fails when: Handled as a support ticket, so it cannot be evidenced at volume
- Primary storeDeletes the records§ 8(7)Fails when: Soft delete presented as erasure
- Queues and cachesStill hold in-flight copiesFails when: Cessation applied to the database only
- Sub-processorsMust also cease§ 8(7)Fails when: No mechanism to propagate, so the instruction stops at your boundary
Serve offshore clients
Process for a client outside India, on non-India Data Principals
- Offshore clientContracts from outside India§ 17(1)(d)Fails when: The exemption assumed to cover the whole business, including India operations
- India delivery teamProcesses the data here§ 8(5)Fails when: Safeguards relaxed because the exemption was read as total
The provisions that apply
Your customer stays liable, whatever the contract says
A Data Fiduciary is responsible for complying with the Act in respect of processing undertaken by it or on its behalf by a Data Processor, irrespective of any agreement to the contrary or a Data Principal's failure to carry out her duties. Liability cannot be contracted onto you. It also means your customer has a direct interest in how you operate, which is why the diligence is intrusive.
A valid contract is mandatory
A Data Fiduciary may engage a Data Processor for any activity related to offering goods or services to Data Principals only under a valid contract. Without one, the customer is in breach by using you. The Act does not enumerate required clauses, so the contract has to be designed around what your customer needs to be able to prove.
You must be able to stop on command
On withdrawal of consent, the Data Fiduciary shall cease and cause its Data Processors to cease processing, within a reasonable time, unless the processing is otherwise required or authorised by law. Your customer needs an interface to make that happen - propagated to backups, queues, caches and any sub-processor - and "reasonable time" is measured against your architecture, not your intentions.
The offshore services carve-out
Chapter II (except sections 8(1) and 8(5)), Chapter III and section 16 do not apply to processing of personal data of Data Principals outside India, pursuant to a contract with a person outside India, by a person based in India. This is the IT and BPO export model, and it stays outside most of the regime - while accountability and security safeguards continue to apply.
What to do about it
Draw the fiduciary/processor line in the schema
Identify which tables hold customer-controlled data and which hold your own users' data. The distinction determines who owes notice, who answers a rights request and who decides retention. Teams that leave it implicit end up applying processor logic to fiduciary data, which is the direction that creates unmet obligations.
Write the DPA around section 8, not around Article 28
A GDPR addendum with the names changed will contain obligations the Act does not impose and miss the ones it does. Build it from what your customer must be able to demonstrate under sections 8(1), 8(2), 6(6) and 8(7) - cessation on withdrawal, erasure on instruction, breach notification into their rule 7 timeline, and sub-processor transparency.
Make erasure and cessation real API operations
Section 8(7)(b) requires the Data Fiduciary to cause its processor to erase data made available to it. If honouring that is a support ticket and a manual script, you cannot evidence it at volume. It should be an endpoint with an audit trail, and it should reach backups and sub-processors.
Get your breach obligations onto your customer's clock
Rule 7 gives the Data Fiduciary specific breach notification duties with tight timelines. They cannot meet them if they hear from you late. Contract your own detection-to-notification window to sit comfortably inside theirs, and test it.
Sequence the work
The same controls as above, in the order they are worth doing. Each names the evidence you would put in front of an auditor, because a control you cannot evidence is a control you cannot prove you had.
Build the foundation
Get the lawful basis and the roles right. Everything else assumes these are settled.
- Process a customer's dataWrite the addendum from sections 8(1), 8(2), 6(6) and 8(7) rather than porting an Article 28 template, and keep a current sub-processor list.Evidence: The executed addendum, the sub-processor register, and the change-notice record.
- Run your own productDraw the Fiduciary and Processor line in the schema, not in the policy. Teams that leave it implicit end up applying processor logic to data they are actually Fiduciary for.Evidence: A data map marking each store with the role you hold for it.
Operationalise it
Turn the basis into systems that run without anyone remembering to run them.
- Honour a cessation instructionMake cessation and erasure real API operations with an audit trail, reaching queues, caches, backups and sub-processors.Evidence: Endpoint logs showing the instruction, the systems reached, and the completion time.
Keep it honest
Prove it still works, and answer the people whose data it is.
- Serve offshore clientsScope the exemption to that engagement. Your own employees, your India customers and their users are outside it entirely.Evidence: Engagement records showing Principal location and contracting party, and safeguards applied regardless.
Section and Schedule references above point at the statute itself. Read them in context in the full text of the Act, or against the MeitY publication. This is an educational summary, not legal advice for your organisation.
SaaS & IT services: common questions
Are we a Data Fiduciary or a Data Processor?
Almost certainly both. You are a Data Processor for the personal data you handle on your customers' instructions, and a Data Fiduciary for the data where you determine the purpose and means yourself - your own account holders, billing records, marketing lists and product analytics. The test is who decides, and it is applied per processing activity rather than per company.
Does the DPDP Act require a specific data processing agreement?
Section 8(2) requires a valid contract, but unlike the GDPR's Article 28 the Act does not enumerate the clauses it must contain. That gives flexibility and removes the safety of a template. The workable standard is a contract that lets your customer discharge their section 8 obligations through you and prove they did.
Do Indian IT services firms working for foreign clients fall under the Act?
Largely not, by design. Section 17(1)(d) disapplies Chapter II - except sections 8(1) and 8(5) - Chapter III and section 16 where an India-based person processes the data of Data Principals outside India under a contract with a person outside India. Responsibility for compliance and reasonable security safeguards still apply, and the exemption does not reach your own employee or customer data in India.
Know this well enough to prove it
The certification is a free, graded 15-question exam covering the Act end to end, not just this sector. Pass mark is 70%.
DPDP Academy Editorial: Legal education and implementation guidance. DPDP Academy Source Review: Primary-source verification against Gazette and MeitY publications; last checked 9 August 2026 against SaaS & IT services implementation guide. Educational information, not legal advice.