Software Product Development Company, security and the DPDP Act: a compliance checklist

Compliance is a property of your product, not of your development partner. India's DPDP Act 2023 places the duties on you as the data fiduciary: lawful consent, purpose limitation, retention limits, breach notification and the ability to erase personal data on request. A competent partner builds those capabilities into the architecture. No vendor certificate grants them to you.

This checklist maps each DPDP obligation to the thing that has to exist in your codebase, sets out the software product development company security baseline we hold ourselves to, and is honest about the points where compliance work is being sold to you ahead of its usefulness.

What the DPDP Act asks a product team to do

The Digital Personal Data Protection Act 2023 uses two roles. A data fiduciary decides why and how personal data is processed, which is you. A data principal is the person the data is about. A development partner processing data on your instructions is a data processor, bound by contract to you rather than directly to the principal for most duties. The Act and the surrounding framework are published by the Ministry of Electronics and Information Technology at meity.gov.in.

Practically, that means five capabilities have to exist in the product itself: a record of what each person consented to and when, processing limited to the stated purpose, deletion when the purpose ends or consent is withdrawn, a way to answer access and correction requests, and enough logging to reconstruct who touched what during an incident. Bolting these on after launch is expensive because they cut across every table and every integration.

Note what the Act does not say. It does not mandate that all personal data stays in India, unlike sectoral rules such as the RBI's payment data direction. It restricts transfer to countries the government notifies against. Teams routinely over-read residency, and we cover that distinction in DPDP Act 2023 and AI: what Indian companies must do.

Obligation to implementation: the mapping table

Every row in that table is engineering work with a cost. Pricing a product build without them and adding them later is the single most common reason a compliance programme runs over budget.

The security baseline underneath compliance

Compliance sits on top of ordinary security hygiene. If the basics are missing, no amount of consent tooling will survive an audit. This is the baseline we build into every product and platform development engagement, whether or not the client mentions DPDP.

• Identity before features. Single sign-on, role-based access control and an append-only audit log, built early rather than retrofitted, as set out in SSO, RBAC and audit logs.
• Least privilege everywhere. No shared admin accounts, no production database credentials on laptops, and time-bound access for support work.
• Encryption as default. TLS on every hop, encryption at rest on managed stores, and key rotation that someone owns by name.
• Environment separation. Production personal data never copied into staging; seeded or masked data instead, which also makes PII redaction a build-time habit rather than an incident response.
• Patch cadence with a clock. Dependency and base-image updates on a published schedule, with an emergency path for critical advisories.
• Third-party register. Every sub-processor listed with what it sees, where it stores it and what the contract says.
• Backups you have restored. An untested backup is a belief, not a control, and restoration tests also expose whether erasure reaches backup media.

What does compliant-by-design cost?

Building these capabilities into a new product adds work but not a separate invoice. Our product and platform development programmes run from $42,000 or ₹28 lakh to $175,000 or ₹1.2 crore, and consent records, retention jobs, audit logging and access controls are scoped inside that, because retrofitting them into a live system with real users costs considerably more than designing them in.

Where the product already exists and the question is how far it is from the standard, a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited against the follow-on build, produces the data inventory, the gap list and a sequenced remediation plan. After launch, the patch cadence, access reviews and incident drills belong in a Care Plan: Essential at $1,000 or ₹68,000 a month, Standard at $2,500 or ₹1,60,000, Enterprise at $5,250 or ₹3,40,000 with one-hour response and a named engineer. Starting prices are published on the pricing page, and our own controls are described on the security page.

Mechanics that people get wrong

Consent is a ledger, not a boolean

A single consent flag on the user row cannot answer the question a regulator asks, which is what this person agreed to, under which version of the notice, on what date, through which channel. Model consent as immutable events with a purpose identifier, and derive the current state from them.

Deletion has to reach every copy

Personal data leaks sideways into search indexes, analytics warehouses, event streams, email service providers and customer support tools. An erasure path that only clears the primary database is a compliance gap with a clean unit test. List every destination during design and give each one a deletion route.

Residency is a contract question as much as an infrastructure one

Choosing an Indian cloud region is the easy half. The harder half is checking which sub-processors your managed services quietly use, where support staff can view data from, and what your own contracts promise your enterprise customers about data residency.

Significant data fiduciaries carry extra duties

The Act allows the government to designate an organisation as a significant data fiduciary based on volume and sensitivity of data, and that designation brings additional obligations such as appointing a data protection officer in India, commissioning independent audits and running impact assessments. If your product is heading for that scale, the audit evidence in the mapping table stops being good practice and becomes something an assessor will ask to see.

Where compliance work is the wrong priority

Not every product needs the full apparatus on day one. A tool that processes no personal data beyond a work email address does not need a consent ledger; it needs good access control and honest documentation. Buying a governance programme for a ten-user internal dashboard is a way of spending budget that should have gone into the product.

Compliance theatre is the second failure mode. Policies written by people who have never seen the schema, annual training with no engineering change, and a certificate on the website while the staging environment holds a copy of production. If the controls are not visible in the code and the pipeline, they do not exist, and we will say so rather than help you decorate.

There is also a sequencing trap. A startup that has not yet found the product will spend three months on a data governance framework for a schema that changes entirely at the next pivot. Build the security baseline, keep a clean data inventory, and add the heavier machinery when the product stabilises or the first enterprise buyer asks.

How this played out on a regulated build

For an NBFC, we built private document intelligence for KYC and loan onboarding where the documents in question are identity records and the regulator is watching. The architecture decisions followed from that: processing inside the client's own environment, access scoped by role, every extraction and every human correction written to an audit trail, and retention set by document class rather than by convenience.

None of that was compliance work bolted onto a product. It was the product, designed for a setting where being able to show who saw a customer's identity document, and when, is part of the job.

Checklist before your next release

• Produce a data inventory: every personal data field, its purpose and its retention period
• Confirm a consent ledger exists with notice version, timestamp and channel
• Trace one erasure request end to end, including search index, warehouse and backups
• List every sub-processor, what it sees and where it stores it
• Check that no production personal data sits in staging or in an analyst's spreadsheet
• Name the breach notification owner and rehearse the timeline once
• Review access grants and remove everything nobody has used this quarter
• Agree who signs off the retention schedule when the product adds a new data class

Related reading

SaaS security checklist for small teams covers the baseline for a team without a security function, AI audit trails: what regulators will ask to see goes deeper on evidence, and the DPDP Act 2023 glossary entry gives your product owner the vocabulary. Read the statute itself rather than a summary of a summary.

Design the consent, retention and erasure paths while the schema is still cheap to change, and compliance stops being a project.