Custom CRM Development, security and the DPDP Act: a compliance checklist
How do you make a custom CRM compliant with India's DPDP Act?
A custom CRM is a personal data system, so India's DPDP Act applies to it in full. Compliance rests on six things built into the schema: a consent record per purpose, purpose tagging, retention rules with automatic deletion, working correction and erasure, role-based access and an audit log.
A custom CRM holds names, phone numbers, addresses and behaviour, so India's Digital Personal Data Protection Act, 2023 applies to it in full and your company is the data fiduciary. Compliance rests on six things designed into the schema: a consent record per purpose, purpose tagging, retention rules with automatic deletion, working correction and erasure, role-based access and an immutable audit log.
This is a checklist rather than a legal analysis. It maps each obligation onto the concrete thing an engineer builds, names the controls that sit outside the Act but that enterprise buyers will ask about anyway, and is honest about which parts can wait and which cannot be retrofitted.
What the Act actually asks of a CRM
The Digital Personal Data Protection Act, 2023, published by the Ministry of Electronics and Information Technology, makes the organisation processing personal data the data fiduciary and the person it belongs to the data principal. In CRM terms, you are the fiduciary and every contact in the database is a principal with rights you must be able to service.
Four duties do most of the work. You need a lawful basis, usually consent, backed by a notice in clear language that says what you collect and why. You must use the data only for the stated purpose. You must keep it no longer than that purpose requires. And you must be able to correct it, erase it, and tell the principal what you hold when asked.
Two further duties change the architecture. The Act requires reasonable security safeguards and notification of a personal data breach to the Data Protection Board and to affected principals. Significant data fiduciaries, a category the government designates by volume and sensitivity, carry heavier obligations including a data protection officer and independent audits. The general background is in DPDP Act 2023 and what Indian companies must do and the term itself in the DPDP Act glossary entry.
Obligation to control: the mapping
Custom CRM development compliance is mostly schema design. Each duty below turns into something concrete, and building them in week two costs a fraction of adding them in year two.
| Obligation | What it means in a CRM | The control you build |
|---|---|---|
| Notice and consent | Every contact reached a database through some route | A consent table: principal, purpose, channel, timestamp, notice version, source |
| Purpose limitation | Marketing must not silently reuse support data | A purpose tag on each field group, enforced at the query layer |
| Accuracy | Stale and duplicated records are a compliance issue, not just a data one | Deduplication job plus a self-service correction route |
| Storage limitation | Lost leads from 2018 have no lawful reason to exist | Retention policy per record type, with a scheduled deletion job and a log |
| Erasure and access rights | Requests arrive by email and get forgotten | A request workflow with an SLA, and a delete that reaches backups and exports |
| Security safeguards | A CRM is the highest-value export target in most companies | Encryption at rest and in transit, role-based access, export limits and alerts |
| Breach notification | You cannot report what you cannot detect | Alerting on bulk reads and exports, plus a written incident runbook |
| Grievance redressal | Someone must be reachable and must answer | A published contact, a ticket queue and a response clock |
Consent, and the field everyone forgets
Record the notice version, not just the tick
A boolean saying consent equals true proves nothing eighteen months later. Store the version of the notice the person saw, the wording of the purpose, the channel, the timestamp and the source, so that when a question arrives you can reconstruct exactly what was agreed. This is the single most common gap we find in existing CRMs.
One consent per purpose
Consent to be contacted about a service enquiry is not consent to receive a monthly newsletter. Model purposes as rows rather than columns, so adding a purpose next year does not require a migration and withdrawal of one does not withdraw all. Withdrawal must be as easy as giving it, which means a working unsubscribe that actually updates the CRM rather than only the email tool.
Children and special cases
The Act requires verifiable parental consent before processing the data of anyone under eighteen, and prohibits behavioural advertising directed at them. Most B2B CRMs never touch this; an education or healthcare CRM does, and it changes the sign-up flow rather than the database.
Retention and deletion, the part that cannot be retrofitted
Deletion is hard because personal data spreads. A contact deleted from the contacts table survives in activity logs, email sync copies, exported reports on a laptop, a data warehouse, a search index and last night's backup. Decide early which copies are authoritative and which are derived, and make derived stores rebuildable rather than independently edited.
Write a retention matrix per record type before the build: active customers for the life of the relationship plus a statutory tail, unconverted leads for a defined period, call recordings for a shorter one. Then implement it as a scheduled job with a deletion log, because a policy document with no job behind it is not a control. Where a record must be kept for tax or regulatory reasons, keep the minimum and mark it, rather than keeping everything and hoping.
Where the data lives
The DPDP Act does not impose blanket localisation. Personal data may generally be transferred outside India, subject to the government restricting transfers to notified countries, so custom CRM development data residency is a commercial and sector question more than a general legal one. If your CRM touches payments or lending, RBI expectations apply and are stricter; RBI guidelines on outsourcing, localisation and audit covers the practical effect. The concept itself is defined in data residency.
Our default for Indian clients is to host in an Indian region because it removes an argument, not because the Act demands it. If you sell to European customers, UK GDPR and the EU regime add their own transfer requirements on top.
Security controls buyers will ask about
- Role-based access with row-level rules. A salesperson sees their accounts, a manager sees the team's, and nobody sees the full export by default.
- Export controls. Bulk export is the real breach vector in a CRM. Rate-limit it, log it, and alert on volume above a threshold.
- Encryption at rest and in transit. Table stakes, but ask specifically about database backups and file attachments.
- Single sign-on and enforced multi-factor authentication. Local passwords in a CRM are a liability; wire it to your identity provider.
- An immutable audit log. Who read what, who changed what, who exported what, retained separately from the application database.
- Masked fields for sensitive attributes. Phone numbers and identifiers masked in list views, revealed on a logged action.
- Secrets and credential hygiene. Integration keys in a secret manager, rotated, never in the repository.
- A tested restore. A backup you have never restored is a belief, not a control.
Breach detection and reporting
You must be able to notice a breach before you can notify one. Alerting on anomalous reads and exports is the CRM-specific control; generic infrastructure monitoring will not catch a legitimate user downloading the whole customer list. Separately from the DPDP Act, CERT-In directions require organisations to report specified cyber incidents within six hours of noticing them, and the Indian Computer Emergency Response Team publishes the applicable categories and reporting channels. Write the runbook while nothing is on fire, and name the person who makes the call.
What compliance work costs
Built in from the start, these controls add a modest amount to a build rather than a phase. Custom ERP and CRM development at Eazyware runs from $28,000 or ₹18,40,000 to $105,000 or ₹72,00,000, with consent modelling, retention jobs, audit logging and access control treated as part of the system rather than an extra, and the scope is set out on the custom ERP and CRM development page with figures on the pricing page. Retrofitting them into a live CRM with three years of data is the expensive version, because it is a migration as well as a build.
After launch, patching cadence and log review sit inside a Care Plan, from $1,000 or ₹68,000 a month for business-hours cover with an eight-hour response up to $5,250 or ₹3,40,000 for 24 by 7 cover with a one-hour response and a named engineer.
Where this checklist is the wrong tool
If you are buying a licensed CRM platform rather than building one, most of these controls exist already and your work is configuration and a data processing agreement, not engineering. Do not commission a bespoke consent module because a checklist written for builders told you to.
The checklist also over-applies to small internal systems. A twelve-person company with a contact list of business buyers still owes those people notice, correction and deletion, but does not need row-level security, an immutable audit store and anomaly alerting on day one. Build the consent and retention model properly, because it cannot be retrofitted cheaply, and add the rest when volume or a customer questionnaire demands it. A security questionnaire for vendors shows what those questionnaires usually contain.
A worked example
An NBFC asked us to process KYC documents for loan onboarding, which is the most sensitive version of this problem: identity documents, a regulated sector and a strict audit expectation. The design answer was to keep processing inside their own environment, redact what did not need to be stored, log every access and make every automated decision reviewable. The engagement is described in the KYC document intelligence case study. A CRM is a milder case of the same discipline.
Related reading
Custom CRM development in India covers pricing and delivery models alongside the data rules, AI audit trails: what regulators will ask to see goes deeper on logging, and questions to ask a custom CRM development vendor includes the security questions worth asking before signature. To review your own design, talk to an engineer.
Consent modelling and retention are architecture; add them in week two or pay for a migration to add them in year three.
Frequently asked questions
Does the DPDP Act require CRM data to be stored in India?
▾
No. The Digital Personal Data Protection Act, 2023 permits transfers outside India, subject to the government restricting transfers to notified countries. Sector rules are stricter: a CRM touching payment or lending data carries RBI storage and audit expectations, and many Indian buyers require domestic hosting contractually.
What consent records should a custom CRM keep?
▾
One row per purpose, holding the data principal, the purpose in plain wording, the channel, the timestamp, the version of the notice shown and the source. A single boolean flag proves nothing later. Withdrawal must be as easy as consent and must update the CRM, not only the email tool.
How long can a company keep CRM records under the DPDP Act?
▾
Only as long as the stated purpose requires, plus any statutory retention such as tax records. Write a retention matrix per record type before the build, implement it as a scheduled deletion job with a log, and make derived stores such as search indexes and warehouses rebuildable rather than separately edited.