SaaS development company, security and the DPDP Act: a compliance checklist

No software is compliant on its own. The Digital Personal Data Protection Act 2023 places duties on you as the data fiduciary: lawful consent, purpose limitation, retention limits, security safeguards, breach notification and erasure on request. A SaaS product is compliant when its architecture can prove each of those, per tenant and per data class, on demand.

This is the checklist we work through when a SaaS development company build touches Indian personal data. It maps each statutory duty to the place in the codebase and the infrastructure where it has to live, because a policy document that is not reflected in a schema is a promise rather than a control.

What the DPDP Act requires of a SaaS product

The Act applies to digital personal data processed in India, and to data processed outside India where the processing relates to offering goods or services to people in India. The text of the Act and the accompanying rules are published by the Ministry of Electronics and Information Technology on its data protection framework page.

Two roles matter. The data fiduciary decides why and how personal data is processed; the data processor processes it on the fiduciary's instructions. If you sell a SaaS product to Indian businesses, you are usually the processor for your customers' data and the fiduciary for your own account and billing data at the same time. Those two hats have different duties, and conflating them is the most common design error we see.

There is no blanket data localisation requirement in the Act, which surprises people. Residency is generally a contract requirement your enterprise customers impose, not a statutory one. What the Act does require is that you can evidence lawful basis, honour erasure, notify breaches and hold data no longer than the purpose justifies. The DPDP Act explained covers the definitions in more detail, and what Indian companies must do covers the organisational side.

Mapping each obligation to the architecture

Read that table as an engineering backlog rather than a legal summary. Every row is a schema change, a job, a runbook or a contract, and each one is cheap in the first release and expensive in the fourth.

Tenant isolation is a compliance control

Choose the isolation model deliberately

Shared schema with a tenant column, schema per tenant and database per tenant are three different compliance postures, not just three architectures. Shared schema is efficient and puts the entire burden on query correctness; database per tenant is expensive and makes residency and erasure trivially demonstrable. Pick with your enterprise pipeline in mind, and read multi-tenant SaaS architecture before you decide, because changing later is a migration rather than a refactor.

Enforce the boundary below the application

A tenant filter applied in application code is one forgotten WHERE clause away from a breach that is also a notifiable incident. Postgres row-level security pushes the boundary into the database, so a missing filter returns nothing rather than everything. We treat that as the default for shared-schema products, and the reasoning is set out in tenant isolation.

Prove it with a test, every deploy

Write a test that authenticates as tenant A and asserts that every endpoint returns nothing for tenant B's identifiers, and run it in the pipeline. It is the single highest-value test in a multi-tenant codebase, and it is the one most teams write only after an incident.

The security controls underneath

• Identity. Single sign-on through SAML or OIDC for enterprise tenants, with role-based access control and a break-glass path that is logged. SSO, RBAC and audit logs covers the build order.
• Encryption. In transit everywhere, at rest for every store including backups, object storage and search indexes. Keys in a managed key service, rotated on a schedule.
• Least privilege. Application roles that can read what they need and nothing else; no shared production credentials; time-bound elevation with an approver.
• Patching. A published cadence for dependencies and base images, with a defined window for critical fixes, as described in security patching cadence.
• Logging. An append-only audit log of who did what to whose data, retained long enough to answer a regulator and short enough to respect retention limits.
• Verification. Build against a graded standard. The OWASP Application Security Verification Standard publishes requirements at three levels, which gives you a defensible answer to an enterprise security questionnaire.
• Subprocessors. A register of every third party touching personal data, with their region, purpose and contract status.

Breach readiness, before you need it

Breach notification duties are the part of the Act that turn an engineering problem into a corporate one overnight. The obligation assumes you can detect an incident, scope which personal data of which people was affected, and report inside a prescribed window. Most young SaaS products fail at the scoping step rather than the detection step: they know something happened and cannot say whose records were touched, because access to personal data was never logged at the row level.

Three things make that survivable. An audit log that records subject identifiers alongside actor and action; a data map that says which tables hold personal data of which class; and a written runbook naming who decides, who drafts the notice and who talks to customers, rehearsed once before it is needed. None of the three is expensive to build in advance, and all three are close to impossible to assemble during an incident.

What does compliance work add to a build?

Done in the first release, consent records, retention jobs, deletion fan-out, audit logging and tenant-boundary tests add a modest slice to a scoped programme. A SaaS or cloud-native build with Eazyware starts at $31,500 or ₹20,80,000 and runs to $126,000 or ₹84,00,000 depending on billing, roles, admin tooling and integrations, and this work sits inside that range rather than beside it. All starting figures are on the pricing page, and what a programme includes is set out on the SaaS development service page.

Done in year three, the same work is a migration. Erasure fan-out is the worst of it, because by then personal data has leaked into analytics extracts, support tickets, spreadsheets and a logging pipeline nobody owns. Budget the first version properly and the ongoing cost is a care plan line rather than a project, from $1,000 or ₹68,000 a month upwards. Our own controls and posture are described on the trust page.

Where a checklist is the wrong tool

A checklist cannot tell you whether a lawful basis is genuinely lawful, whether your notice is intelligible to the person reading it, or whether your retention period is defensible for your purpose. Those are judgement calls that need a privacy lawyer who has read your product, and no architecture diagram substitutes for one.

It is also the wrong tool if your product is not yet handling real personal data. Building a full consent and retention apparatus around a prototype with nine test users delays the thing that would tell you whether the product is worth compliance effort at all. Instrument the schema so the controls can be added, then add them before the first real customer, not before the first demo.

And if you are selling into the EU or the UK as well, do not build two regimes. Model the strictest requirement once. The consent, retention and erasure design that satisfies GDPR will satisfy DPDP with a change of vocabulary, which is the approach in GDPR and systems: a builder's guide.

What this looks like on a real system

For an NBFC handling KYC documents and loan onboarding, the controls were not optional and the data could not leave the customer's own environment. The system we built runs inside their infrastructure with document processing, validation and audit trails in place, described in the KYC document intelligence case study. The design principle that drove it is worth borrowing: decide where data is allowed to be before you decide what the software does with it.

For most business-to-business SaaS products the equivalent decision is smaller but the same in shape. Pick your region, write down what may never leave it, including logs and backups, and make that a deployment constraint rather than a policy paragraph.

Related reading

SaaS security checklist for small teams covers the practical baseline for a team without a security engineer, a security questionnaire for vendors covers what your enterprise buyers will send you, and row-level security covers the database-level enforcement in more depth.

Compliance is not a document you produce at the end; it is a set of columns, jobs and tests you can point at when somebody asks.