Enterprise Platform Implementation Services, security and the DPDP Act: a compliance checklist
How do you make an enterprise platform implementation compliant with India's DPDP Act?
Under India's DPDP Act you remain the data fiduciary for every record in the platform, and your implementation partner is only a processor. Compliance is therefore architectural: residency you control, retention enforced as fields, masked migration data and an audit trail that survives cutover.
Under India's Digital Personal Data Protection Act 2023 you remain the data fiduciary for every personal record inside the platform, and your implementation partner is a processor acting only on your documented instructions. Compliance is therefore architectural rather than contractual: residency you control, purpose and retention enforced as fields, masked migration data, and an audit trail that survives cutover.
Most DPDP guidance is written for a running system. Platform implementations fail the Act somewhere else: in the migration rehearsals, the test environments, the integration payloads and the support access granted during hypercare. This checklist covers those, with the evidence a regulator or an internal auditor will actually ask to see.
What the DPDP Act requires of a platform implementation
The Act assigns duties to the data fiduciary, which is your organisation, not the software vendor and not us. You must have a lawful basis for processing, give notice of purpose, collect only what the purpose needs, keep it only as long as the purpose lasts, secure it with reasonable safeguards, report breaches, and honour data principal rights including access, correction and erasure. The statute and its rules are published by the Ministry of Electronics and Information Technology, and our plain-language summary sits at DPDP Act 2023.
Two of those duties are quietly expensive in an implementation. Purpose limitation means the platform must record why each field exists, which forces a conversation nobody wants about the forty legacy columns whose purpose nobody remembers. Erasure means a delete request has to reach every copy, including the reporting warehouse, the integration queue and the six months of migration snapshots someone left in an object store.
Separate from the DPDP Act, CERT-In's directions require covered entities to report specified cyber incidents within six hours of noticing them, and to retain logs for a rolling period. That obligation lands on the implementation too, because it determines how your logging is built and where it is kept. The directions are published at cert-in.org.in.
Obligations mapped to what you actually build
This is the mapping we work through during architecture on every enterprise platform implementation engagement. The third column is what an auditor asks for, and it is the column most programmes cannot produce.
| DPDP duty | What it means in the implementation | Evidence to keep |
|---|---|---|
| Purpose limitation | Every personal data field in the target model carries a stated purpose and an owner | Field-level data dictionary signed off by the process owner |
| Data minimisation | Legacy columns with no stated purpose are dropped at migration rather than carried across | Migration mapping showing fields dropped and the reason |
| Storage limitation | Retention is a configured rule that deletes or anonymises, not a policy document | Retention configuration export plus evidence of a completed purge run |
| Security safeguards | Encryption at rest and in transit, role-based access, and no shared administrator accounts | Access matrix by role and a key management description |
| Breach reporting | Detection and escalation defined before go-live, with the reporting clock understood | Runbook, on-call rota and a tested escalation dry run |
| Data principal rights | Access, correction and erasure reach every copy including reports and backups | A rights request walkthrough executed end to end in a test tenant |
| Processor obligations | Your partner and every sub-processor act on documented instructions only | Signed agreement, named sub-processor list, audit rights clause |
| Residency and control | Production runs in an Indian region inside your own cloud account | Account ownership, region configuration and egress rules |
Seven controls we build into the programme
These are not policy items. Each is a piece of work with an owner and a place in the plan.
- Masked migration data. Rehearsals run on extracts with names, identifiers and contact details substituted. Only the final rehearsal and the cutover itself touch production data, on a shortened access window.
- Non-production without personal data. Development, test and training environments are seeded synthetically. This is the single control that removes the most risk, and the one most often traded away for speed.
- Role-based access from day one. Permissions are modelled in the target platform before users are loaded, using role-based access control rather than the incumbent system's accumulated exceptions.
- Named, time-bound support access. Hypercare engineers get individual accounts with an expiry date, not a shared admin login. Access is revoked on a calendar entry, not on trust.
- Redaction at the integration boundary. Payloads leaving the platform carry only the fields the receiving system needs, with PII redaction applied to logs and error traces.
- Immutable audit trail. Who saw what and who changed what, written to a store the application cannot rewrite, as described in our note on the audit log.
- A tested erasure path. A deletion request is executed end to end in a test tenant before go-live, including the warehouse and the queue, so that the first real request is not an experiment.
Where implementations actually leak
Migration rehearsals
Migration is rehearsed four or five times, and each rehearsal produces a full copy of production data in a lower environment. Those copies outlive the project. Set a deletion date for every extract at the moment it is created, store extracts in a single bucket with an object lifecycle rule, and reconcile the list of copies at every phase gate.
Spreadsheets in the cleansing phase
Data cleansing is where personal data ends up on laptops, in shared drives and in email threads, because cleansing is a business activity and the business uses spreadsheets. Give the team a controlled cleansing workspace inside the platform or the data pipeline, and make the exported spreadsheet the exception that needs approval.
Integration payloads
Integrations are usually built by exchanging a full record because it is quicker than agreeing a contract. Full records then land in message queues, retry stores and error logs where nobody has retention rules. Agree the minimum field set per integration during design and keep the payload schema in version control.
The support window after go-live
Hypercare grants broad access to people who need it urgently, and the access is rarely withdrawn. Time-box it in the plan and treat revocation as a go-live exit criterion alongside the reconciliation report. Our approach to access and security practice is documented on the security page.
Residency, sub-processors and the cloud account question
The Act does not currently ban cross-border transfer outright, but sector regulators and customer contracts frequently do, and the safest architecture is the one that makes the question uninteresting. Run production in an Indian region inside a cloud account your organisation owns, so that data residency is a configuration fact you can screenshot.
Then enumerate the sub-processors, because this is where residency quietly breaks. A translation service, an email relay, an error-tracking tool, a support desk or an analytics tag can each move personal data outside the perimeter without appearing on any architecture diagram. List every third party the platform calls, mark where each processes data, and remove or replace the ones you cannot justify. For BFSI buyers, the RBI's outsourcing expectations add audit rights and an exit plan on top of this.
For control selection rather than legal duty, the OWASP Application Security Verification Standard is a practical baseline to specify against in the statement of work, and it is published openly at owasp.org.
What compliance adds to cost and schedule
Done during design, these controls add little. Retrofitted after go-live they are expensive, because retention and redaction touch the data model. Eazyware quotes platform implementation from $28,000 or ₹18,40,000 to $140,000 or ₹1 crore with this work inside the scope rather than as a compliance phase bolted on the end. Ongoing security patching and access reviews sit in a Care Plan, from $1,000 or ₹68,000 a month on Essential to $5,250 or ₹3,40,000 a month on Enterprise; the tiers are listed on the pricing page.
When this checklist is not the right tool
If your programme handles payment card data, health records under a hospital's own obligations, or data covered by a foreign regulator such as UK GDPR, the DPDP checklist is necessary but not sufficient, and you need the sector standard as the governing document with DPDP layered on top. Running a single checklist and assuming it covers everything is how organisations discover a gap during an audit rather than during design.
It is also the wrong tool if the honest answer is that you should not hold the data at all. The cheapest compliance work is deleting a field, and a surprising share of legacy columns fail the purpose test the moment someone is asked to justify them in writing.
What this looked like on a regulated programme
An NBFC needed document processing for KYC and loan onboarding, where the source documents are about as sensitive as Indian personal data gets. The system was built to run inside their own infrastructure with no document leaving their perimeter, redaction applied before anything reached a log, and every access recorded. The engagement is described in private document intelligence for KYC. The architectural decision, not the policy document, is what made the review straightforward.
Related reading
DPDP Act 2023 and AI: what Indian companies must do covers the statute in general terms, data migration for platform implementations goes deeper into the cleansing phase where most leakage happens, and sovereign AI in India addresses the residency question for enterprises with stricter constraints.
Treat DPDP compliance as a set of fields, permissions and deletion jobs you can demonstrate, not as a clause you can point at.
Frequently asked questions
Who is responsible under the DPDP Act, us or our implementation partner?
▾
You are. Your organisation is the data fiduciary for personal data in the platform and carries the duties of notice, purpose limitation, retention, security and breach reporting. The implementation partner is a processor acting on documented instructions, so your contract should name sub-processors and grant audit rights.
Does the DPDP Act require our platform to run inside India?
▾
The Act does not impose a blanket localisation requirement, but sector regulators and customer contracts frequently do. Running production in an Indian cloud region inside an account you own makes residency a verifiable configuration fact and removes the argument, which is why we treat it as the default architecture.
What is the most common compliance gap in a platform implementation?
▾
Copies of production data left in lower environments after migration rehearsals, and personal data exported to spreadsheets during cleansing. Both sit outside the platform's own controls, so retention and access rules never reach them. Set a deletion date on every extract when it is created and audit the list at each phase gate.