DPDP Act23 May 2026 7 min read

DPDP Act for SaaS Companies: Obligations and Controls

How the DPDP Act applies to Indian SaaS companies — dual role as Data Fiduciary and Data Processor, DPA obligations, security controls, and how to turn compliance into a sales asset.

Key Takeaways

SaaS companies are typically Data Processors for customer-uploaded data and Data Fiduciaries for their own account holder data.
DPDP Act compliance is increasingly a procurement requirement — enterprise customers will ask for your compliance posture.
DPA availability is a prerequisite for enterprise sales — ensure your standard DPA is DPDP Act-compliant.
Security safeguards (Section 8(5)) apply equally to SaaS companies as processors and as fiduciaries.
SOC 2 compliance and DPDP Act compliance are complementary — both demonstrate security and privacy maturity.

In this guide

The Dual Role: Fiduciary and Processor
Your Own Data: Fiduciary Obligations
Customer Data: Processor Obligations
Offering a DPA to Your Customers
Security Controls for SaaS DPDP Compliance
DPDP Compliance as a Sales Asset
SOC 2 and DPDP Act: Where They Overlap

The Dual Role: Fiduciary and Processor

Most B2B SaaS companies operate in two simultaneous roles under the DPDP Act. They are Data Fiduciaries for data they collect directly — account holder information, billing data, product usage analytics, and marketing databases. They are Data Processors for personal data that customers upload to the platform — customer's customer records, HR data, financial data, or any other personal data processed on the customer's behalf.

Each role carries different obligations. As a Fiduciary, you must: obtain consent for your own data collection, publish a privacy notice, implement security, respond to rights requests from your users, and notify the Board of breaches. As a Processor, your obligations flow from your contracts with customers — you must implement security safeguards, notify customers of breaches, and process data only per their instructions.

The boundary between the two roles is not always obvious. If you use customer-uploaded data to train your AI models, improve your product, or create aggregated benchmarking reports — even anonymised — you may be acting as a Fiduciary for processing that goes beyond your customer's instructions. Review your terms of service carefully to ensure you do not inadvertently claim broad rights over customer data that create Fiduciary obligations you have not accounted for.

Your Own Data: Fiduciary Obligations

For data you collect directly — account registration (name, work email, company, role), product usage analytics, support tickets, marketing opt-ins — you are a Data Fiduciary with the full set of obligations. This means: a privacy notice covering what you collect and why; specific consent for each processing purpose (analytics, marketing, product communications); a consent withdrawal mechanism; a rights request process; security controls; and breach notification capability.

Review your product analytics setup. Most SaaS companies use Mixpanel, Amplitude, Segment, or similar tools. These tools process personal data (user IDs, session data, event data linked to identifiable users) and require consent under the DPDP Act. Implement a consent gate before loading analytics SDKs, or switch to privacy-friendly analytics that do not require consent.

Your marketing database deserves particular attention. Email lists, webinar registrant lists, trial sign-up lists, and lead databases are personal data under the Act. Every contact requires a valid lawful basis — typically consent. Audit your marketing database: how was each contact added? Was consent given? Is the consent still valid? Re-permissioning campaigns before enforcement begins are advisable for older lists.

Customer Data: Processor Obligations

For personal data that your customers upload to your platform, you are a Data Processor. Your obligations as a Processor are primarily contractual — flowing from your DPA with each customer. But the practical requirements are significant: implement security safeguards equivalent to what a reasonable Data Fiduciary would implement; notify customers of breaches promptly; process data only for the purposes specified in the DPA; and delete or return data at contract end.

Your technical architecture should support processor obligations: customers should be able to extract their data (and their customers' data) on request; deletion requests must be processed across all data stores including backups; data should be logically segregated per customer; and access controls must prevent cross-customer data access.

Sub-processing is a common issue for SaaS companies. When you use AWS, Google Cloud, Snowflake, Intercom, or any other third-party service that processes your customers' data, you have engaged a sub-processor. Your DPA with customers must either authorise specific sub-processors or provide a mechanism for you to notify and add sub-processors. Maintain a current, accurate sub-processor list and make it accessible to customers.

Offering a DPA to Your Customers

Enterprise customers will increasingly require a Data Processing Agreement before contracting with you. Your DPA should cover all required elements: nature and purpose of processing, categories of personal data, security requirements, breach notification (within 24 hours of your becoming aware), sub-processor list and authorisation mechanism, and data return/deletion at contract end.

Make your standard DPA easily accessible — add a link to it in your standard service agreement, on your website's security page, and in your sales process. Requiring customers to request a DPA, negotiate it from scratch, and wait weeks for approval creates friction that loses deals. Enterprise procurement teams will disqualify you if you cannot produce a DPA quickly.

Review your DPA against DPDP Act requirements now. Many SaaS companies have DPAs drafted for GDPR compliance — these need to be updated to reflect DPDP Act obligations, particularly the Section 8(6) breach notification requirement (all breaches, no risk threshold), the cross-border transfer framework (whitelist-only, once published), and the nominee rights provisions.

Security Controls for SaaS DPDP Compliance

Section 8(5) applies to you both as a Fiduciary (for your own data) and through your DPA as a Processor (for customer data). The security controls you need to implement overlap significantly with SOC 2 Type II security requirements: encryption at rest and in transit, access controls, penetration testing, vulnerability management, and incident response.

DPDP-specific security considerations for SaaS: implement customer data isolation at the infrastructure level (not just at the application layer); build breach detection that can identify which customers' data was affected by a security incident; implement audit logging of access to personal data; and ensure your backup and disaster recovery procedures include secure deletion capability for customer data.

Publish your security practices. A security page on your website (sometimes called a "trust page") that describes your encryption standards, access controls, certifications, and incident response commitment helps enterprise customers complete their vendor due diligence faster. Link to your SOC 2 report or ISO 27001 certificate from this page.

DPDP Compliance as a Sales Asset

DPDP compliance is increasingly a procurement requirement for Indian enterprise customers. Large companies, banks, and government-adjacent organisations are beginning to include data protection compliance questions in their vendor questionnaires. A SaaS company that can respond confidently — with a privacy notice, a DPA, security certifications, and a documented compliance programme — has a significant advantage over competitors who cannot.

Create a compliance brief or trust report for your sales team — a document that summarises your DPDP compliance posture: your role (Processor for customer data, Fiduciary for account data), your DPA availability, your security certifications, your breach notification commitments, and your data residency options. This document answers 80% of the questions enterprise procurement will ask.

As DPDP enforcement begins, compliance will become a hard requirement, not just a differentiator. SaaS companies that have invested in compliance now will close deals that competitors without compliance cannot. Position your compliance investment as a feature, not a cost — it enables access to compliance-sensitive enterprise segments that are often the highest-value customers.

SOC 2 and DPDP Act: Where They Overlap

SOC 2 (specifically the Security, Availability, and Confidentiality Trust Service Criteria) and DPDP Act Section 8(5) (reasonable security safeguards) have significant control overlap. SOC 2 CC6 (logical and physical access controls), CC7 (system operations and incident response), and CC9 (risk management) address many of the same controls as DPDP's security obligation.

Key SOC 2 controls that directly satisfy DPDP Act security obligations: encryption at rest and in transit (CC6.7); access management and role-based access (CC6.1, CC6.2); incident detection and response (CC7.3, CC7.4); change management and vulnerability management (CC8.1). A company that has achieved SOC 2 Type II certification has a strong security programme that goes a long way towards satisfying DPDP Act security requirements.

The gaps are in the privacy-specific obligations. SOC 2's Privacy criteria (P1-P8) address privacy programme elements but are not specifically calibrated to the DPDP Act's consent, notice, rights, and breach notification requirements. AuditPath maps DPDP Act obligations to SOC 2 controls, allowing you to manage both frameworks in a single compliance programme and maximise the return on your compliance investment.

Frequently Asked Questions

Our SaaS platform is used by Indian and non-Indian customers. Does DPDP Act apply to all customer data?

DPDP Act applies to personal data collected or processed in India. For your Indian customers uploading personal data of Indian residents, DPDP Act applies. For non-Indian customers uploading data about non-Indian individuals, DPDP Act may not apply (GDPR or other local laws might). Your DPA should identify which customer data is subject to DPDP Act obligations.

Can we store customer data in AWS US regions, or do we need India data residency?

Once the cross-border transfer whitelist is published, you can transfer data to whitelisted countries including (most likely) the US. Until the whitelist is published, the transfer framework is not yet in force. For customers that contractually require India data residency (common in financial services and government sectors), offer an India-region deployment option using AWS Mumbai or Azure India regions.

Do we need customer consent to use their usage data to improve our product?

If you use identifiable usage data (linked to specific users or companies), this is processing of personal data for a purpose — product improvement — that requires a lawful basis. Consent from your account holders (the Data Fiduciary) is the most straightforward basis, or disclose it as a legitimate use in your ToS and DPA. Ensure your privacy notice and terms accurately describe this use.

We have a free tier with many users. Do DPDP Act obligations apply to free users?

Yes. DPDP Act obligations apply regardless of whether the user is on a paid or free tier. Free users' personal data (email, usage data, product interactions) is subject to the same consent, notice, rights, and security obligations. Free tiers often have less formal account management but must not have lower data protection standards.

Can SOC 2 Type II certification substitute for DPDP Act compliance?

No — but it gets you most of the way there for the security obligation. SOC 2 Type II certification demonstrates operational security controls but does not address consent management, privacy notices, Data Principal rights, breach notification to the Board, or vendor DPA obligations. Use SOC 2 as your security foundation and add DPDP-specific privacy controls on top.