CRM data protection: keeping your customer data safe in India

1. Why CRM data is sensitive

Your CRM is not just a contact list. It is a concentrated repository of your most valuable business relationships. Think about what a typical CRM record contains: the client’s full name, their personal mobile number, their email address, their company name, their designation, the value of deals you are negotiating with them, notes about their budget constraints, internal information about their decision-making process, and often personal details gleaned from conversations — birthdays, family mentions, preferences.

Now imagine that data in the wrong hands. A competitor gains access to your entire client list with deal values and buying timelines. A disgruntled former employee downloads your contact database before their last day. A security breach exposes your clients’ personal phone numbers and email addresses to the open internet. Any one of these scenarios is catastrophic — not because of the data itself, but because of what it represents: trust.

Your clients shared their information with you in confidence. Mr. Sharma gave you his personal mobile number because he trusts your company, not because he wanted it stored in an unsecured spreadsheet that seventeen people can access. When that trust is broken — through a data leak, a privacy violation, or simple carelessness — the damage goes far beyond regulatory fines. It destroys relationships that took years to build.

2. The DPDP Act 2023 and what it means for CRM users

India’s Digital Personal Data Protection Act, 2023 (DPDP Act) is the country’s first comprehensive data protection legislation. If your CRM stores personal data of Indian citizens — and if you are running a business in India, it almost certainly does — this law applies to you. Not just to your CRM vendor, but to you as the “data fiduciary” who collects and processes that data.

Here is what the DPDP Act means in practical terms for CRM users:

• Consent for data collection. You need a lawful reason to store personal data in your CRM. For most B2B businesses, this is straightforward — the data is necessary for a legitimate business relationship. But you cannot scrape phone numbers from the internet, dump them into your CRM, and start cold-calling without any consent framework.
• Right to erasure. If a contact asks you to delete their data, you must be able to do it. This means your CRM must support permanent deletion of a record, not just archiving or soft-deleting. Can you prove that Mr. Patel’s data has been completely removed from your system? If not, you have a compliance gap.
• Data breach notification. If there is a breach — even an accidental exposure — you are required to notify the Data Protection Board of India and, in some cases, the affected individuals. Having audit logs in your CRM that show who accessed what and when becomes critical for breach investigation.
• Data localisation preferences. While the DPDP Act does not mandate strict data localisation for all businesses, it gives the government the power to restrict cross-border data transfers to certain countries. For industries like financial services, the RBI has already issued guidelines requiring that payment data be stored within India. Knowing where your CRM stores data — and having the option to keep it in India — is increasingly important.
• Penalties are significant. The DPDP Act prescribes penalties of up to ₹250 crore for certain violations. While enforcement is still evolving, the direction is clear: India is moving towards stricter data protection, and businesses that ignore it now will pay later.

3. Security features to look for in a CRM

Not all CRMs treat security equally. Some treat it as a checkbox on a marketing page. Others build it into the architecture from day one. Here is what you should look for when evaluating a CRM’s security posture:

• Encryption at rest and in transit. Your data should be encrypted when it is stored on the server (at rest) and when it travels between your browser and the server (in transit, via TLS/HTTPS). This is non-negotiable. If your CRM vendor cannot confirm both, walk away.
• Role-based access control (RBAC). Not everyone on your team should see everything. A junior salesperson should not have access to the entire client database. A manager should see their team’s data but not other teams. RBAC lets you define who sees what based on their role, and a good CRM enforces this at the API level — not just the UI level.
• Audit logs. Every action taken in the CRM — who created a record, who edited it, who deleted it, who exported data — should be logged with timestamps. Audit logs are essential for compliance, breach investigation, and simply knowing what happened when something goes wrong.
• Two-factor authentication (2FA). Passwords alone are not enough. If a team member’s password is compromised (and in India, where password reuse is rampant, this happens more than anyone admits), 2FA ensures that the attacker still cannot access your CRM without the second factor — typically a time-based code from an authenticator app.
• Session management. What happens when a user logs in from a new device? Can you see active sessions and revoke them? If a salesperson’s phone is stolen, can an admin immediately invalidate all their sessions? Proper session management prevents unauthorised access even after credentials are compromised.
• Tenant isolation. If you are using a multi-tenant SaaS CRM (which most cloud CRMs are), your data must be completely isolated from other customers’ data. A bug in another tenant’s configuration should never expose your records. This is an architecture-level decision that we will discuss in the next section.

4. Multi-tenancy risks and schema isolation

Most cloud CRMs are multi-tenant, which means multiple businesses share the same application infrastructure. This is normal and cost-effective. But the way data is isolated between tenants matters enormously for security.

There are two common approaches to multi-tenant data storage:

5. Where is your data stored?

“In the cloud” is not an answer. The cloud is someone else’s computer, and it matters where that computer physically sits. For Indian businesses, data residency has both practical and regulatory implications.

Many global CRMs store data in US or European data centres by default. This means every time your salesperson in Mumbai opens a contact record, the request travels to a server in Virginia or Frankfurt, and the response travels back. The latency is noticeable — especially on Indian mobile networks. More importantly, your customer data is subject to the legal jurisdiction where it is stored. Data in the US can be subpoenaed under US law, even if your business is entirely Indian.

Regional hosting matters for three reasons:

• Performance. A server in Mumbai (AWS ap-south-1) responds 3–5x faster for Indian users than a server in US-East. For a CRM that your team uses hundreds of times per day, those milliseconds add up to a noticeably snappier experience.
• Regulatory compliance. The RBI has already mandated that payment system data be stored in India. While CRM data is not directly covered by this mandate today, the trend is clear — the DPDP Act gives the government power to restrict cross-border transfers at any time. Being ahead of this curve is prudent.
• Client confidence. When you tell a client “your data is stored in India on AWS Mumbai” versus “your data is somewhere in the cloud,” the confidence gap is enormous. Especially for clients in regulated industries like banking, insurance, or government contracting.

6. 10 questions to ask your CRM vendor about security

Before you sign up for any CRM, ask these ten questions. A vendor who cannot answer them clearly — or worse, seems annoyed by them — is not a vendor you should trust with your customer data.

7. How TatvaCRM handles security

We believe the best way to build trust is transparency. Here is exactly how TatvaCRM protects your data, with technical detail, because vague reassurances are not enough when your clients’ personal information is at stake.

• Password hashing with bcrypt (cost factor 12). We never store plain-text passwords. Every password is hashed using bcrypt with a cost factor of 12, making brute-force attacks computationally impractical. Account lockout triggers after 5 failed login attempts for 15 minutes.
• JWT + session cookie architecture. Authentication uses short-lived JWT tokens (15 minutes) for API access, backed by session cookies (httpOnly, Secure, SameSite=Lax) for persistence. The raw session token goes to the client; a SHA-256 hash is stored in the database. Even if the database is compromised, the actual session tokens remain secure.
• Role-based access control (RBAC) with 5 system roles. Owner, Admin, Manager, Member, and Viewer — each with precise permission sets (35 granular permissions). Tenants can also create custom roles with any permission and visibility combination. RBAC is enforced at the API level, not just the UI.
• Encrypted TOTP two-factor authentication. 2FA uses time-based one-time passwords (TOTP) compatible with any authenticator app (Google Authenticator, Authy, etc.). The TOTP secret is encrypted before storage, adding a layer of protection even if the database is accessed directly.
• Schema-per-tenant PostgreSQL isolation. Every business gets a dedicated PostgreSQL schema. Your data is physically separated from every other customer’s data at the database level. A bug in the application cannot cross schema boundaries.
• Audit logs for compliance. Every create, update, and delete operation is logged with the user, timestamp, and the specific changes made. These logs live in the tenant’s own schema — isolated from other tenants and available for export at any time.
• Rate limiting and brute-force protection. Global rate limiting at 100 requests per minute, with stricter limits on authentication endpoints (10 requests per minute). This prevents credential-stuffing attacks and automated abuse.
• Admin IP binding. System admin accounts can be restricted to specific IP addresses, ensuring that even with valid credentials, admin access is only possible from authorised network locations.

Security is not a feature you add after launch. It is an architecture decision you make before writing the first line of code. TatvaCRM was built with schema isolation, bcrypt hashing, JWT sessions, and RBAC from the very first commit.

No system is perfectly secure — anyone who claims otherwise is either naive or dishonest. But there is a vast difference between a CRM that treats security as a marketing bullet point and one that implements it at every layer of the stack. We chose the harder path because your clients trusted you with their data, and you are trusting us with it. That chain of trust is not something we take lightly.