Custom Enterprise Software Development, security and the DPDP Act: a compliance checklist

Compliance is a property of what you build, not of the word custom. A bespoke system satisfies India's DPDP Act only when consent capture, purpose limitation, retention limits, erasure, access control and breach reporting are designed into it. The advantage of a custom build is that each of those controls sits where you put it, rather than where a vendor's roadmap allows.

This is the checklist we work through on every custom enterprise software development engagement that touches personal data: what the Act obliges a data fiduciary to do, where each obligation lands in the architecture, what the security work costs, and the cases where building your own system makes compliance harder rather than easier.

What the DPDP Act asks of a business application

The Digital Personal Data Protection Act, 2023 governs digital personal data processed in India, and personal data processed outside India where the processing relates to offering goods or services to people in India. Your company, as the entity deciding why and how the data is processed, is the data fiduciary. The person the data is about is the data principal.

Five duties drive almost all of the engineering. You must process personal data only for a lawful purpose the person has consented to or that falls under a legitimate use. You must give notice of that purpose in clear language. You must stop processing and erase data when consent is withdrawn or the purpose is served. You must apply reasonable security safeguards. And you must report a personal data breach. The Ministry of Electronics and Information Technology publishes the Act and the rules made under it on its data protection framework page, which is the source to check before your legal review rather than a summary blog.

Two extra tiers matter for larger builds. An organisation notified as a Significant Data Fiduciary carries additional duties including a data protection officer based in India, independent audit and periodic impact assessment. Children's data carries a verifiable parental consent requirement, which is an architectural decision, not a policy paragraph, because you cannot retrofit an age gate into a schema that never recorded one. The DPDP Act glossary entry sets out the definitions in plain language.

Where each obligation lands in the architecture

The checklist before your first release

Run this before code freeze, not before launch. Each item is a build task with an owner and a test, and each one is materially cheaper now than after go-live.

• Draw the data map. Every personal field, where it enters, where it is copied to, and how long it lives. If you cannot draw it, you cannot defend it.
• Write purposes as code, not as prose. Each field carries the purposes it may serve, and the query layer refuses anything else.
• Build erasure early. A deletion request must reach the primary database, the warehouse, search indexes, caches, exports and the backup policy. Retrofitting this is the single most expensive compliance repair we are asked to do.
• Separate identity from behaviour. Keep direct identifiers in one table, referenced by a key, so analytics and reporting can work on pseudonymised data.
• Turn on row-level access. Sales sees their accounts, support sees their tickets, and nobody has a blanket select. The row-level security glossary entry explains the pattern.
• Redact in logs and exceptions. Personal data in a stack trace is still personal data and usually escapes your perimeter to a monitoring vendor.
• Register every processor. Model providers, email senders, SMS gateways, analytics tools, error trackers. Each is a transfer with a contract behind it.
• Rehearse the breach runbook once. A tabletop exercise before launch beats a first attempt during a real incident.

Does the DPDP Act require data to stay in India?

No, not as a blanket rule. The Act permits transfer of personal data outside India except to countries the government restricts by notification, which is a narrower rule than the localisation many buyers assume. Sector regulators are the stricter constraint: the Reserve Bank of India's payment data storage direction, insurance and securities guidance, and contractual commitments to your own enterprise customers often demand Indian storage regardless of what the Act allows.

In practice that means the residency decision belongs in the architecture, not in the contract annexe. Deploy the primary data store in an Indian region, keep an inventory of every path by which data leaves it, and make each of those paths switchable. The data residency glossary entry describes the levels we design to. If your build uses a hosted model API, that is an outbound path, and the redaction layer in front of it is a compliance control, not an optimisation.

What the security and compliance work costs

On a custom and enterprise software development programme, which starts at $24,500 or ₹16,00,000 and runs to $175,000 or ₹1.2 Cr, the consent ledger, purpose enforcement, erasure fan-out, access model and audit log are typically ten to fifteen per cent of build effort when designed in from the first sprint. The same controls retrofitted after launch routinely cost two to three times that, because the schema, the exports and the integrations all have to be reopened. Published starting prices are on the pricing page.

Compliance does not end at go-live. Patch cadence, dependency advisories, access reviews and log retention are ongoing work, which is what a Care Plan covers: $1,000 or ₹68,000 a month on Essential with an eight-hour response in business hours, $2,500 or ₹1,60,000 on Standard with cover twenty-four hours across five days, and $5,250 or ₹3,40,000 on Enterprise with a one-hour response, round-the-clock cover and a named engineer. The tiers are described under software maintenance and support.

Where teams get this wrong

Consent captured once and never versioned

A consent record without the version of the notice it was given against is close to useless in an audit. Store the notice text or its hash alongside the consent, so you can say what the person actually agreed to in March.

Erasure that stops at the primary database

The row goes, and the same person survives in the analytics warehouse, three CSV exports on a shared drive and a search index nobody owns. Erasure is a distributed operation, and the register of destinations is the artefact that makes it possible.

Admin accounts that see everything

Most access-control failures in enterprise builds are not sophisticated. They are a support tool with an unrestricted view, used daily, logged nowhere. Give the support tool the same row-level rules as the application and log every lookup with a reason code.

When a custom build is the wrong route to compliance

If your obligation is narrow and well understood, an established platform with a compliance posture you can inherit is often the faster answer. Building your own consent management, audit logging and access control makes sense when the workflow is genuinely specific to your business. It makes very little sense when you are rebuilding a standard HR or accounting function and the real requirement is an audit trail the vendor already ships.

Custom is also the wrong choice when nobody internally will own the controls. A consent ledger with no owner degrades within two quarters. If you cannot name the person who will run access reviews next year, buy a system where someone else is accountable for that, and spend your engineering budget where the business is actually differentiated.

What this looks like in practice

For an NBFC processing KYC documents, the constraint was that customer identity documents could not leave the client's environment, which ruled out a straightforward hosted pipeline. The system was built so that extraction ran inside their perimeter, personal fields were pseudonymised before anything reached a reporting layer, and every document access was logged against an operator and a case. The KYC document intelligence case study describes the approach, and it is the same shape any regulated build takes: decide the perimeter first, then design the features that can live inside it.

Related reading

DPDP Act 2023 and AI: what Indian companies must do covers the obligations at company level rather than application level, and SSO, RBAC and audit logs goes deeper on the access model that most of this checklist depends on. Our security page sets out how we handle client data during an engagement.

Build the consent ledger, the erasure fan-out and the access log in the first month, because every week you delay them adds a system they will later have to reach into.