If you're the CTO or IT lead at a 100 to 300 person Indian company, here's the uncomfortable truth: every SaaS tool your team uses that touches personal data makes your company a Data Fiduciary under the Digital Personal Data Protection Act 2023. That means the HR software storing Aadhaar-linked records, the CRM holding 50,000 customer email addresses, and the Slack workspace where someone pasted a customer's KYC scan last Tuesday — all of it is now a compliance surface.
The DPDP Act's enforcement framework is firming up through 2025. The Data Protection Board is being constituted, rules are being notified in tranches, and the penalties for non-compliance go up to ₹250 crore per instance. That's not a theoretical risk; it's a structural one baked into how most Indian mid-market companies buy and use SaaS.
This checklist is written for the person who has to actually do something about this — not read about it. We'll go vendor category by vendor category, cover what a valid Data Processing Agreement looks like, walk through the audit steps, and give you a model for maintaining compliance without hiring a full-time DPO.
What the DPDP Act Actually Changes for SaaS Buyers
The Digital Personal Data Protection Act 2023 creates a two-party structure that every IT lead needs to internalize. Your company is the Data Fiduciary — you determine the purpose and means of processing. Your SaaS vendor is the Data Processor — they process data on your instructions. The legal obligations, including consent management, breach notification, and individual rights fulfilment, land primarily on you, not the vendor.
Indian SaaS buying behaviorers the personal data of Indian citizens regardless of where that data is processed. A US-hosted CRM storing Indian customer records is within scope. A Singapore-based payroll tool processing your employees' salary data is within scope. Geography of the server doesn't create an exemption.
The three operational obligations that land squarely on IT leads are: maintaining verifiable consent records before processing begins, executing Data Processing Agreements with every vendor that handles personal data on your behalf, and having a breach notification mechanism capable of meeting the expected 72-hour reporting window to the Data Protection Board.
Action: Map your current SaaS stack against these three obligations this week. If you can't answer "yes, we have a signed DPA" for your top 10 data-touching tools, that's where you start.
Which SaaS Vendor Categories Carry the Highest DPDP Risk
SaaS contract exit clauses India with the sensitivity of data processed and the volume of data subjects involved.
Tier-1 risk: HR and HRMS platforms. Tools like Darwinbox, Keka, and Zoho People hold some of the most sensitive data in your stack — Aadhaar numbers, PAN, salary history, health insurance details, performance records. Under the DPDP Act, health data and government ID data are classified as sensitive personal data, attracting stricter obligations. A breach here isn't just a regulatory problem; it's a direct harm to real employees.
Tier-2 risk: CRM and marketing automation. Salesforce, HubSpot, Leadsquared, and similar tools process customer PII at scale — names, contact numbers, email addresses, behavioural data, purchase history. The consent chain here is particularly complex because data enters the CRM from multiple sources: web forms, sales calls, third-party lead vendors. Each source needs its own consent trail.
Tier-3 risk: Productivity and collaboration tools. Google Workspace, Slack, Notion, and Microsoft 365 sit in a slightly different category. The tools themselves don't collect sensitive data by design, but employees routinely paste sensitive customer data, contracts, and HR information into them. This makes them processors of personal data in practice, even if not by intent.
The often-overlooked categories are the ones that catch companies off guard: expense management platforms (which process employee names, amounts, GST numbers), payroll processors like Razorpay Payroll or Greythr, and background verification APIs plugged into your HRMS. Each of these processes personal data and needs a DPA.
A SaaS tool your IT team doesn't know about is a tool with no Data Processing Agreement, no breach protocol, and no contractual path to incident notification.
Shadow IT amplifies every risk tier. When a sales manager signs up for a prospecting tool using the company credit card and a work email, that tool is processing customer PII under your company's Data Fiduciary obligations — with zero IT oversight and almost certainly no DPA.
Key takeaway: Tier your SaaS stack by data sensitivity before you audit DPA coverage; the tier-1 tools are where a compliance gap causes the most damage.
Log this expense in Easexpense in 30 seconds
Data Processing Agreements: What You Need and From Whom
A Data Processing Agreement is a contract between you (Data Fiduciary) and your vendor (Data Processor) that governs exactly how they may handle personal data on your behalf. Under the DPDP Act framing, a valid DPA needs to address four things at minimum: purpose limitation (the vendor can only use data for the service you've contracted), retention schedules (data must be deleted when the purpose is fulfilled), sub-processor disclosure (you need to know who else touches your data downstream), and a breach notification SLA that gives you enough time to meet your own regulatory obligations.
Most enterprise SaaS vendors publish a standard DPA on their legal or privacy page. For vendors like Microsoft and Google, the India-specific DPA addendum is accessible through the admin console. For Zoho, the updated privacy framework aligned to DPDP obligations is available on their legal page. For smaller Indian SaaS vendors, you may need to request one explicitly — and many are still drafting them.
The difference between a standard DPA and a negotiated addendum matters when your use case involves sensitive personal data or unusually large volumes. A standard DPA covers common obligations. A negotiated addendum lets you specify shorter breach notification windows, stronger data deletion timelines, or India-specific data residency commitments. For tier-1 tools, it's worth asking your legal counsel whether a negotiated addendum makes sense.
Watch out: If a vendor routes your DPA request to a generic [email protected] email and goes quiet for 3 weeks, treat that as a compliance red flag. Vendors who take data obligations seriously have a documented process for DPA requests.
One practical clause to look for: the DPA should require the vendor to notify you of any personal data breach "without undue delay and no later than 48 hours of becoming aware." This gives you buffer to meet the expected 72-hour window to the Data Protection Board.
Running a DPDP Audit on Your SaaS Stack: Step by Step
An audit sounds formal, but for a 100-person company it can be done in a focused week. Here's the sequence that works.
Step 1: Inventory every active SaaS subscription. This includes tools bought by department heads outside IT procurement. The finance team's expense software, the marketing team's SEO tool paid via the company Amex — all of it. If you don't have full visibility, scan corporate email inboxes for recurring invoices. Payment receipts from Stripe, Chargebee, or direct vendor billing tell you exactly what's active.
Step 2: Classify each tool by the data category it touches. Four buckets: PII (names, email, phone), sensitive personal data (Aadhaar, PAN, health, financial), financial data (transaction records, account numbers), or none. Be honest about bucket 3 (productivity tools) — classification by what employees actually do with the tool, not just what the vendor markets it as.
Step 3: Check for an executed DPA in your contract records. For every tool in the PII or sensitive personal data bucket, pull your contract folder. If there's no DPA, add it to a remediation list with a deadline.
Step 4: Verify consent mechanisms for customer-facing tools. Check the web forms, app onboarding flows, and lead capture widgets connected to your CRM. Pre-ticked consent boxes are explicitly non-compliant. Bundled consent (one checkbox that covers five different processing purposes) won't hold up.
Step 5: Log the sub-processors disclosed by each vendor. A vendor's DPA should list or link to their sub-processors. Cross-reference this list for any sub-processors storing data outside India, which feeds into the cross-border transfer analysis in the next section.
Using Keep Expense to maintain a vendor register is straightforward: one row per subscription, with custom fields for data category, DPA status, DPA expiry date, and the name of the internal owner responsible for renewal and compliance review. This becomes a living compliance artefact, not a spreadsheet that goes stale.
Data Localization, Cross-Border Transfers, and the SaaS Grey Zone
The DPDP Act restricts cross-border personal data transfers to countries on a government-approved whitelist. As of mid-2025, this whitelist has not been formally published. That creates a genuine grey zone for any US-hosted or EU-hosted SaaS tool that processes Indian personal data.
The practical posture right now: document your data flows, push for in-region storage where available, and treat data localization as a configuration task rather than a legal emergency — while accepting that the rules will crystalize over the next 12 months.
For cloud infrastructure and SaaS tools with data residency options, use the Indian regions: AWS ap-south-1 (Mumbai), Azure India Central (Pune), and Google Cloud asia-south1 (Mumbai). Many enterprise SaaS platforms now expose a region selector in their admin settings. Check it. Changing the default from US East to ap-south-1 is a 2-minute admin task with meaningful compliance upside.
For SaaS vendors that don't offer Indian data residency, your interim step is documentation. Maintain a data flow register that captures: which tool processes what data, which region stores it, what the vendor's DPA says about cross-border transfers, and what sub-processors they use. When the whitelist is published, this register tells you immediately which tools need action.
Action: Log into the admin console of your top 5 data-touching SaaS tools this week and note the data residency setting. If it's US or EU by default and an Indian region is available, switch it.
Vendors that already offer Indian data residency as a standard option include Microsoft 365 (India Data Boundary program), Google Workspace (India region available on Business and Enterprise plans), AWS (ap-south-1 is a first-class region), and Zoho (data centres in Chennai). Vendors that currently don't include many US-focused CRMs and niche vertical SaaS tools — these require a negotiated addendum or a compliance risk acceptance from your legal team.
Key takeaway: While the cross-border whitelist is pending, configure every tool to use Indian data regions where the option exists, and document everything else — that documentation is your defensible due diligence.
Consent Records and the SaaS Tools That Complicate Them
The DPDP Act requires consent that is free, specific, informed, unconditional, and unambiguous — with a clear mechanism for withdrawal. This sounds straightforward until you map it against how most SaaS-powered customer journeys actually work.
Consider a typical marketing stack: a visitor fills a HubSpot form, gets added to a Mailchimp sequence, their data is synced to Salesforce, and a retargeting pixel fires to Meta. Each of these is a separate processing activity. A single checkbox saying "I agree to the privacy policy" doesn't create the specific, granular consent the Act requires for each purpose.
Pre-ticked boxes are explicitly out. Bundled consent for multiple purposes is legally fragile. And the Act requires that you can prove consent was obtained — not just assert it. That means consent records with timestamps, the exact consent language shown, and the data subject's identifier.
For most mid-market companies, a full consent management platform (CMP) is overkill. What you actually need is an audit of your lead capture forms and marketing automation workflows, and a consent record store tied to your CRM. HubSpot, Salesforce, and Zoho CRM all have built-in consent fields — they're just rarely configured correctly out of the box.
Check your onboarding flows for these three failure patterns: consent bundled with terms of service acceptance, no withdrawal mechanism visible post-signup, and consent collected once at lead capture but not refreshed when processing purpose changes (e.g., when a lead becomes a customer and is added to a different communication stream).
Breach Notification and Incident Response Across a Multi-SaaS Stack
The DPDP Act mandates notification to the Data Protection Board and affected individuals within a prescribed window — rules are pending, but the expected standard is 72 hours from the fiduciary becoming aware of a breach. The challenge in a multi-SaaS environment is that "becoming aware" depends entirely on your vendors telling you.
If your HR tool suffers a breach and you don't have a DPA with a 48-hour vendor notification clause, you might find out via a news article on day 4. At that point, you're already outside the regulatory window.
The minimum viable incident response setup for a 100-person company has three components. First, a vendor contact list: for every tier-1 and tier-2 SaaS tool, who do you call at 11 PM when there's an incident? This isn't the support email; it's the security team contact or the enterprise account manager. Second, DPA breach clause references: know exactly what each vendor has contractually committed to in terms of notification timing. Third, an internal escalation path: who in your company gets the notification, who calls legal, and who drafts the communication to affected users?
The SaaS vendor register we described in the audit section doubles as your incident response foundation. A row per tool, with the breach notification contact and the DPA clause reference, is enough to move fast when it matters.
Key takeaway: Your breach response speed is directly proportional to how well your vendor register is maintained — a DPA without a vendor contact list is half a safety net.
Building a Sustainable DPDP Compliance Posture Without a Full-Time DPO
Most companies between 50 and 300 employees don't need a dedicated Data Protection Officer right now. The Act reserves the DPO obligation for "Significant Data Fiduciaries" — a category the government will notify based on data volume and sensitivity thresholds. For the typical mid-market B2B SaaS or services company, compliance ownership lands on the CTO or senior IT lead by default.
The governance model that works at this scale is lightweight by design. Assign a compliance owner per vendor tier — tier-1 tools need quarterly review, tier-2 tools can be reviewed semi-annually. Track DPA expiry dates the same way you track subscription renewals: in your vendor register, with alerts set 60 days in advance. A DPA that expires and isn't renewed is the same as having no DPA.
Embed DPDP checks into your SaaS procurement workflow. Before any new tool is approved, three questions get answered: what personal data will it process, is there a DPA available, and does the vendor offer Indian data residency. This takes 15 minutes per tool evaluation and prevents the compliance debt from compounding.
Our AI CIO can surface new SaaS tools as they appear in your stack — including the ones bought without IT approval — and flag them for compliance review before they've been running for 6 months with no DPA. This is exactly the kind of shadow IT problem that creates DPDP exposure without anyone intending it.
When to bring in external legal counsel: when you're drafting a negotiated DPA addendum with a tier-1 vendor, when an incident occurs, or when you're assessing whether your company might meet the Significant Data Fiduciary threshold. For everything else — vendor classification, consent flow audits, data residency configuration — your IT team can handle it with the right tooling and a clear framework.
The Easexpense marketplace includes several DPDP-aligned vendor options with India-region data storage, which cuts down the configuration work when you're onboarding a new tool and want to start from a compliant baseline.
Action: Create one row per SaaS vendor in your subscription tracker today, add columns for Data Category, DPA Status, DPA Expiry, and Compliance Owner. Schedule a 30-minute review in Q3. That's your DPDP governance system — it doesn't need to be more complicated than this.
Frequently asked questions
Does the DPDP Act apply to SaaS tools used internally by employees, not just customer data?
Yes, the Act covers processing of personal data of any individual, including employees. HR tools, payroll software, and internal communication platforms that store employee contact details, salary data, or performance records fall within scope. The distinction between "customer-facing" and "internal" tools doesn't exist in the Act's framework — what matters is whether personal data of any individual is being processed. IT leads need to treat employee data in SaaS tools with the same rigour as customer data, which means your HRMS, your payroll processor, and even your leave management tool all require DPAs. Sensitive personal data categories like health information, government IDs, and financial records attract stricter obligations regardless of whether the data subject is a customer or an employee.
What is a Data Processing Agreement and do I need one with every SaaS vendor?
A Data Processing Agreement is a contract that defines how a vendor (acting as a Data Processor) may handle personal data on your behalf. You need one with every SaaS tool that processes personal data belonging to your customers or employees — names, email addresses, phone numbers, financial data, health records, government IDs all qualify. Tools that handle only anonymised or aggregated data where re-identification is genuinely impossible may not require one, but when in doubt, request it anyway because the effort of getting a DPA is far lower than the liability of not having one. Many enterprise SaaS vendors have a standard DPA available on their legal or privacy page, often accessible without needing to speak to a sales team. The key is to execute the DPA formally, store a copy in your contract records, and track its expiry date alongside your subscription renewal date.
Which Indian SaaS vendors already have DPDP-compliant Data Processing Agreements?
As of mid-2025, vendors like Zoho, Razorpay, and Freshworks have published updated privacy frameworks aligned with DPDP Act obligations, and their DPAs are accessible through their respective legal pages without a lengthy negotiation process. Microsoft and Google have India-specific DPA addendums available through their admin portals — Microsoft through the Microsoft Products and Services Agreement portal, Google through the Google Workspace admin console. Smaller Indian SaaS vendors are still catching up, and some have GDPR-aligned DPAs that don't explicitly address DPDP obligations, so verify the specific clauses rather than assuming GDPR compliance equals DPDP compliance. For vendors that don't yet have a published DPDP DPA, you can request that they sign your own standard DPA template — many will do so, especially if you're an enterprise customer with negotiating leverage.
Can I store Indian customer data on AWS or Google Cloud servers outside India?
The DPDP Act permits cross-border data transfers only to countries on a government-approved whitelist, which had not been formally published as of mid-2025. This creates genuine uncertainty for US-hosted or EU-hosted cloud workloads processing Indian personal data. The safest interim posture is to configure your cloud workloads to use Indian regions (AWS ap-south-1 Mumbai, Azure India Central, Google Cloud asia-south1 Mumbai) and document this configuration decision in your data flow register as evidence of due diligence. Review your vendor's terms carefully to confirm where data is stored by default, because the default region in most global SaaS tools is US East or EU West, not India, and this matters for your compliance posture. When the whitelist is published, update your register to assess which existing configurations need to change.
What happens if a SaaS vendor we use suffers a data breach? Are we liable under DPDP?
As the Data Fiduciary, your company bears the notification obligations to the Data Protection Board and to affected individuals even if the breach originated at a vendor's infrastructure. The Act doesn't create an exemption just because the breach wasn't your technical fault — you're responsible for the personal data you collected and entrusted to a processor. Your DPA with that vendor should include a clause requiring them to notify you within a defined window, typically shorter than your own regulatory deadline, so you have time to meet the expected 72-hour reporting requirement. If you don't have a DPA in place, you have no contractual right to timely notification, no documented defence of due diligence, and no agreed process for joint response. This is why the DPA isn't just a compliance formality — it's the operational contract that determines whether you can actually respond to an incident within the regulatory window.
How do I find out which SaaS tools my company is actually using, including ones IT does not know about?
Shadow IT is the single biggest blind spot in any DPDP compliance effort, and it's more pervasive than most IT leads realise — our data across Easexpense customers shows that the typical 100-person Indian company has between 15 and 25 SaaS tools that finance and IT don't officially track. The fastest way to surface shadow IT is to scan your corporate email inboxes for recurring subscription invoices and payment receipts, because even tools signed up with a personal credit card almost always send billing receipts to a work email address. Once you have that full list, classify each tool by the data it processes and prioritise which ones need a DPA immediately. Connecting your Gmail or Google Workspace to the Easexpense mail discovery feature surfaces these subscriptions automatically, organised by vendor and spend — which gives you both the compliance inventory and the spend picture in one pass.
Does the DPDP Act require a company to appoint a Data Protection Officer?
The Act allows the government to notify certain categories of "Significant Data Fiduciaries" who must appoint a DPO, but this designation hasn't been applied broadly to mid-market companies as of mid-2025. Companies processing standard volumes of customer and employee data — a few hundred thousand records — are unlikely to meet the Significant Data Fiduciary threshold immediately. That said, someone internally must own the compliance function and be identifiable as the point of accountability if the Data Protection Board has questions. In practice, this falls on the CTO or senior IT lead at most companies between 50 and 300 employees, supported by an external legal advisor for high-stakes decisions. As the company scales past 500 employees or begins processing sensitive personal data at significant volume, a dedicated compliance role — even a part-time fractional DPO arrangement — starts to make more sense than continuing to treat it as a side responsibility of the engineering team.