Full Stack Development Company, security and the DPDP Act: a compliance checklist

No full stack development company is DPDP compliant as a standing property. Compliance sits with you as the data fiduciary, and the company you hire either builds the mechanisms the Act requires or leaves you exposed. What you can verify before signing is whether consent capture, purpose tagging, retention jobs, erasure endpoints and breach detection exist in the code you are buying.

This checklist is written for the person who has to sign the contract and later answer a regulator. It maps each obligation in the Digital Personal Data Protection Act, 2023 onto the specific artefact in a web application that satisfies it, gives you the questions that separate a real answer from a reassuring one, and states what the work costs.

What the DPDP Act actually asks of a web application

The Digital Personal Data Protection Act, 2023 is India's general data protection law. It names you, the business collecting the data, as the data fiduciary; your development partner and your cloud provider are data processors acting on your instructions. Liability does not transfer down the chain. A processor's failure is still your penalty, which is why the contract and the architecture matter more than a vendor's compliance badge.

The Act's text, published by the Ministry of Electronics and Information Technology, runs to fewer than fifty sections and is worth an hour of your lead engineer's time. The obligations that bite in ordinary web software are notice and consent, purpose limitation, erasure when the purpose is served, accuracy, reasonable security safeguards, breach reporting, and the rights of the data principal to access, correction and grievance redressal. The Schedule sets penalties as high as ₹250 crore for failing to take reasonable security safeguards.

Two points surprise teams. First, consent under the Act must be a clear affirmative action for a specified purpose, so a pre-ticked box or a bundled "I agree to everything" is not consent. Second, the Act does not impose blanket data localisation; it allows transfer to any country the Central Government has not restricted. Sectoral rules are stricter, and an RBI-regulated payments flow still localises. Our DPDP Act 2023 guide covers the statutory ground; this post stays in the codebase. The short definition is in the DPDP Act glossary entry.

Obligation by obligation: what it means in the codebase

Compliance becomes tractable when each clause is reduced to a thing an engineer can build, test and show you.

The controls we build into every stack

These are not optional extras we quote separately. They are the default shape of a web application we hand over, and you should expect any serious partner to work the same way.

• A consent ledger, not a boolean. One row per purpose per grant, with version, timestamp and the exact notice text shown. Withdrawal writes a new row rather than editing the old one.
• Purpose tags on schema columns. Personal data is annotated at the column level and the annotation is reviewed in code review, so nobody quietly reuses a phone number collected for delivery in a marketing campaign.
• Retention jobs with a dry-run mode. Deletion that runs on a schedule, logs what it removed, and can be rehearsed before it is armed.
• A data subject request endpoint. Access, correction and erasure served by code paths that are tested, not by an engineer running ad hoc SQL against production.
• PII out of application logs. Redaction at the logger, because logs and traces are where personal data most often escapes a well-designed database.
• Least privilege by default. Role-based access control, row-level security in Postgres where tenants share tables, and no standing production database access for developers.
• An immutable audit trail. Who saw what, who changed what, and when, retained long enough to answer a question you have not been asked yet.
• Tested restores. A backup you have never restored is a hypothesis. We restore into a scratch environment on a schedule and record the result.

Several of these overlap with what enterprise buyers ask for anyway, which is why we treat them as product features rather than compliance overhead. The pattern is described in more detail in SSO, RBAC and audit logs.

What does DPDP readiness cost?

On a new build it is not a separate line item, which is the honest answer most buyers do not expect. Our full stack web application development engagements run from $14,000 or ₹8,80,000 up to $63,000 or ₹41,60,000, and the consent model, retention jobs and audit trail are inside that scope because retrofitting them costs several times more than building them once. All starting figures are on the pricing page, and we invoice in INR with GST for Indian clients.

Retrofitting an existing application is different work and is scoped separately. The usual shape is a two to three week audit that produces a data map, a gap list and a remediation plan, followed by a build. Where the data map itself is the hard part, a ten-day Sprint Zero through our discovery sprint at $3,250 or ₹2,00,000, credited to the build, gets you the inventory before you commit to a budget.

Compliance also has a running cost. Dependencies need patching, certificates expire, and a retention job that silently fails is worse than no retention job. Our Care Plans start at $1,000 or ₹68,000 a month for business-hours cover with a ten-hour monthly allowance, and go to $5,250 or ₹3,40,000 a month for 24x7 cover with a one-hour response and a named engineer. The detail sits on the maintenance and support page.

Security underneath the compliance layer

Identity and session handling

Most breaches we are called in to review are authentication failures, not exotic exploits. Sessions bound to a single device fingerprint, short-lived tokens, refresh rotation, and multi-factor authentication for anything with administrative reach are the baseline. Password reset flows deserve the same threat modelling as login.

Data at rest and in transit

TLS everywhere, encryption at rest through the managed database rather than a bespoke scheme, and a documented key rotation policy. Where a column holds something genuinely sensitive, such as a government identifier, application-level encryption on that column limits what a database dump reveals.

Third parties are your surface too

An analytics tag, a chat widget and a session replay tool each read personal data in the browser. Each one needs a place in your notice, a sub-processor entry and a decision about residency. Session replay in particular records form fields nobody intended to capture.

Residency decisions made once, deliberately

Decide where the primary database, the backups, the logs and the object store each live, write it down, and make the answer the same across environments. The data residency glossary entry sets out the options. Staging environments seeded with production data are the most common quiet breach of a residency policy.

Where a checklist is the wrong tool

A checklist tells you whether controls exist. It cannot tell you whether they work, and three situations call for something else.

If you do not know what personal data you hold, start with discovery, not controls. Teams that implement consent screens over an unmapped estate end up with a record describing only the flows somebody remembered. If you are in a regulated sector, DPDP is the floor rather than the ceiling: RBI, IRDAI and SEBI expectations on localisation, outsourcing and audit sit on top, and a generic checklist will miss them. And if your exposure is concentrated in a fifteen-year-old system nobody wants to touch, a compliance project on the new web application is displacement activity; the honest answer is a modernisation programme scoped against the real risk.

What this looks like on a real build

Our work with an NBFC on KYC and loan onboarding is the clearest example we can point to. Identity documents are about as sensitive as Indian personal data gets, so the system was designed around a private deployment, redaction before anything left the processing boundary, and an exception queue where a human decides rather than a model deciding silently.The engagement is written up in the KYC document intelligence case study. The general lesson transfers to ordinary web applications: design the audit trail first and the compliance conversation becomes a demonstration rather than an argument.

Questions to ask before you sign

• Show me the consent schema from your last three projects, not a slide about consent
• Which retention job deletes which table, and when did it last run successfully?
• How do you serve an erasure request that touches backups, logs and a warehouse?
• Where do the primary database, the backups and the logs physically sit?
• Who on your team has standing access to our production data, and how is it logged?
• What is your patch cadence for dependencies with published advisories?
• What does the data processing agreement say about sub-processors and deletion on exit?
• On exit, what exactly do we receive, and in what format?

Related reading

DPDP Act 2023 and AI covers the statutory obligations in full, Security patching cadence for production applications explains the maintenance discipline that keeps safeguards reasonable over time, and A security questionnaire for AI vendors gives you the procurement version of these questions. For the statute itself, start at the Ministry of Electronics and Information Technology and read the Schedule of penalties before the sections.

Treat DPDP as an architecture requirement you build once rather than a certificate you buy, and the audit becomes a walkthrough of things that already exist.