Application Maintenance and Support Services, security and the DPDP Act: a compliance checklist
What does the DPDP Act require from an application maintenance and support provider?
Under India's DPDP Act you stay the data fiduciary and your support vendor is a processor acting only under a valid contract. Four things become contractual: scoped production access with an audit trail, purpose-limited use of personal data, deletion on withdrawal of consent, and fast breach notification.
Under India's Digital Personal Data Protection Act 2023 you remain the data fiduciary and your support vendor is a data processor acting only under a valid contract. Four things therefore become contractual rather than discretionary: scoped production access with an audit trail, purpose-limited use of personal data, deletion when consent is withdrawn, and breach notification fast enough to meet your own obligation.
This checklist maps each DPDP duty onto the day-to-day reality of maintaining an application, names the controls that satisfy it, states honestly where the Act is quieter than people assume, and gives you the evidence pack an auditor or an enterprise customer will ask for.
Who is the fiduciary and who is the processor?
A data fiduciary is the organisation that determines why and how personal data is processed. A data processor processes it on the fiduciary's behalf. If you own the application and its users, you are the fiduciary, and no maintenance contract transfers that. The vendor holds the keyboard; you hold the accountability.
That asymmetry is the whole reason a support engagement needs more paperwork than it used to. Your vendor's engineers will, at some point, read a production record to reproduce a defect. The Act does not forbid that. It requires that the processing happens under a contract, for your purposes only, with security safeguards in place, and that you can show afterwards who looked at what. The definitions are set out in the DPDP Act glossary entry, and the wider obligations for Indian companies are covered in DPDP Act 2023 and AI.
One consequence catches people out. If your vendor uses a subprocessor, a monitoring platform, an offshore engineer, a translation service, that relationship has to flow down from your contract. A support provider who cannot list their subprocessors on request is a gap in your compliance posture, not just in theirs.
Mapping DPDP duties onto a support contract
Each row below states an obligation, what it actually means when someone is debugging a production incident at midnight, and the artefact you show when asked to prove it.
| DPDP duty | What it means in support work | Evidence to keep |
|---|---|---|
| Processing only under a valid contract | A signed data processing agreement naming purposes, systems and subprocessors | Executed DPA with a current subprocessor annexe |
| Purpose limitation | Production data is read to fix a defect, never copied into a test dataset | Access request tickets linked to incident IDs |
| Security safeguards | Named individual accounts, multi-factor authentication, least privilege, session recording | Access matrix and quarterly access review minutes |
| Erasure on withdrawal of consent | Deletion reaches backups, logs, caches and lower environments, not just the primary table | Deletion runbook plus a completed erasure log |
| Retention limits | Support logs and ticket attachments expire on a schedule | Retention policy per data store with automated enforcement |
| Breach notification | Vendor alerts you fast enough for you to notify the Board and affected principals | Incident response plan with a named escalation clock |
| Records for audit | Every production access and every patch is attributable to a person and a reason | Immutable audit log retained for the agreed period |
| Cross-border transfer | Transfers are permitted except to countries the Central Government restricts | Data flow map naming every jurisdiction touched |
The controls that do most of the work
Seven controls close the majority of the gap between an ordinary support arrangement and a defensible one. None of them is expensive; all of them are easier to build at onboarding than to retrofit after an audit.
- Named accounts with just-in-time elevation. Shared logins destroy attributability. Engineers hold read-only access by default and request elevation against a ticket, with automatic expiry.
- Masked lower environments. Copying production into staging is the single most common breach vector in maintenance work. Refresh with masked or synthetic data, and treat PII redaction as part of the pipeline rather than a manual step.
- Attachment hygiene in tickets. Screenshots and log extracts pasted into a helpdesk become an uncontrolled copy of personal data. Strip them, or keep the helpdesk inside the same retention and access regime as the application.
- Log scrubbing at source. Application logs should not carry identifiers, card fragments or health details. Fix this in the logging layer, not with a downstream cleaner.
- A patching cadence with evidence. Unpatched dependencies are a security safeguard failure. A monthly window, an out-of-band path for critical advisories and a recorded rollback plan are described in our note on security patching cadence.
- Quarterly access reviews. Every quarter, the list of people with production access is read line by line by someone who knows whether each still needs it. Leavers are the most common finding.
- A rehearsed erasure path. Practise a deletion request end to end once, including backups and search indexes, before a real one arrives.
Does the DPDP Act require Indian data residency?
No, not as a blanket rule. The DPDP Act permits transfer of personal data outside India except to territories the Central Government restricts by notification, which is a narrower position than the localisation many buyers assume. The Act itself is published by the Ministry of Electronics and Information Technology at meity.gov.in, and reading the transfer provision directly is worth ten minutes of anyone's time.
Sectoral regulation is the stricter constraint. Banking and payments carry storage requirements from the Reserve Bank of India, insurance and securities regulators have their own expectations, and many enterprise contracts impose residency regardless of statute. So the practical answer for most Indian applications is that data stays in an Indian region, not because DPDP demands it, but because your regulator or your largest customer does. The trade-offs are unpacked in the data residency glossary entry.
Where it bites in support work is the support desk itself. If your ticketing platform, monitoring stack or paging tool stores data outside India, that is a cross-border transfer even though nobody thought of it as one. Map the tools, not just the application.
What does compliant support cost?
Less than most people expect, because the controls are engineering hygiene rather than a separate programme. Access management, masked environment refreshes, log scrubbing and an audit trail are part of onboarding on every Eazyware maintenance and support engagement. Care Plans start at $1,000 or ₹68,000 per month for Essential with business-hours cover in IST, $2,500 or ₹1,60,000 for Standard at 24x5 with a four hour response, and $5,250 or ₹3,40,000 for Enterprise at 24x7 with a one hour response and a named engineer. Applications with AI components add $750 or ₹40,000 per month for evaluation runs, prompt regression and re-indexing. The tiers are published on the pricing page, and our own posture is documented on the security page.
The cost that does surprise people is the deletion path. Implementing erasure that genuinely reaches backups, replicas, caches and search indexes is a piece of engineering, often two to three weeks on an older system, and it is worth scoping before you promise a customer anything.
When this checklist is the wrong priority
If your application holds no personal data at all, a scheduling tool for machinery, an internal build system, a pricing calculator with no user accounts, most of this is ceremony. Confirm the claim with a data inventory rather than a memory, then spend the effort on availability instead.
It is also the wrong first move when the application has an unresolved structural problem. A system where every engineer shares one database login because the application has no role model does not need a policy document; it needs role-based access control built. Writing a compliance annexe over an architecture that cannot enforce it produces paperwork you will fail against.
And a caution on vendor questionnaires. A long security questionnaire returned quickly is weaker evidence than a short one answered with specifics, as we argue in a security questionnaire for AI vendors. Ask for the access matrix and a sample audit log export instead.
What this looks like on a real system
An NBFC we work with processes KYC documents containing identity numbers, addresses and income evidence, which is about as sensitive as Indian personal data gets. The architecture keeps documents inside their own cloud account, exposes support access through named accounts with time-boxed elevation, redacts identifiers before anything reaches a log, and records every exception review against a case ID. The build is described in the KYC document intelligence case study. The maintenance arrangement inherited those controls rather than inventing new ones, which is the point: compliance in support is mostly a question of whether the original design left room for it.
The evidence pack to assemble
- Signed data processing agreement with a current subprocessor list
- Data inventory naming every store that holds personal data, including logs and tickets
- Access matrix showing who holds which production permission and why
- Last two quarterly access review records, with leavers removed
- Retention schedule per store, with the automation that enforces it
- Erasure runbook and one completed end-to-end test
- Incident response plan with the notification clock written in hours
- Data flow map showing every jurisdiction your support tooling touches
Related reading
Our guide to what belongs in an application maintenance contract covers the commercial clauses that sit alongside these controls, and AI audit trails explains what regulators actually ask to see when a decision was automated. If you want the checklist run against your estate and your current vendor, send us the system list.
Compliance in application support is not a document; it is whether you can name, six months later, who read that record and why.
Frequently asked questions
Does the DPDP Act apply to an outsourced support vendor?
▾
Yes, as a data processor. The vendor may process personal data only under a valid contract with you, for your purposes, with security safeguards in place. You remain the data fiduciary and stay accountable to the Data Protection Board, so the contract, the access controls and the audit trail are your responsibility to require.
Must support data stay inside India under DPDP?
▾
Not as a blanket rule. The Act permits transfers abroad except to territories restricted by government notification. Residency usually comes instead from sectoral regulators such as the Reserve Bank of India or from enterprise customer contracts. Remember that ticketing, monitoring and paging tools count as transfers if they store data offshore.
What security controls should a maintenance contract specify?
▾
Named individual accounts with multi-factor authentication, least-privilege access with time-boxed elevation against a ticket, masked data in lower environments, log scrubbing at source, a documented patching cadence with rollback, quarterly access reviews, an immutable audit log, and a breach notification clock stated in hours rather than days.