Encryption Basics for Indian Businesses: Data at Rest and in Transit

Encryption is the primary technical control that keeps customer data safe even when an attacker reaches your database, intercepts network traffic, or steals a hard drive. For Indian businesses, it is also a legal requirement: the DPDP Act 2023 mandates "reasonable security safeguards," and both RBI and PCI-DSS explicitly require encryption of sensitive financial data. This guide explains symmetric and asymmetric encryption, TLS for data in transit, encryption at rest at the disk, database, and field level, key management, and how to avoid the mistakes that make encryption useless in practice — without heavy mathematics.

$4.45MAverage global cost of a data breach in 2023 (IBM Cost of a Data Breach 2023)

Top 3encryption gaps in Indian SaaS: no TLS on internal APIs, plaintext passwords, missing field-level encryption (VAPT assessment patterns)

Why Encryption Is Not Optional for Indian Businesses

Indian regulators have made their position clear. The DPDP Act 2023 (Section 8) requires data fiduciaries to implement "reasonable security safeguards to prevent personal data breach." MeitY's draft rules cite encryption as an exemplar control. The RBI Master Direction on IT Governance (2023) mandates encryption for customer financial data in transit and at rest. PCI-DSS 4.0, binding on any business that touches card data, requires TLS 1.2+ in transit and strong encryption for stored PANs.

An unencrypted database is not a technical gap — it is a compliance gap and a board-level liability.

🚨

DANGER

Storing plaintext passwords, API keys, or Aadhaar numbers in a database column is an immediate P0 finding in any VAPT audit. It cannot be mitigated by firewall rules or access controls alone — once the DB is dumped, every credential is exposed.

Symmetric vs Asymmetric Encryption: Practical Difference

Symmetric encryption uses one key to both encrypt and decrypt. AES-256 is the global standard. It is fast and well-suited for large data — your database columns, disk images, and file archives. The challenge is key distribution: both sides need the same key, so sharing it securely is the hard problem.

Asymmetric encryption uses a key pair: a public key (shared freely) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key. RSA-2048 and ECDSA are the dominant algorithms. Asymmetric operations are computationally heavier — unsuitable for bulk data encryption. In practice, asymmetric encryption is used to securely exchange a symmetric key, not to encrypt the data itself. TLS does exactly this.

Property	Symmetric (AES-256)	Asymmetric (RSA/ECDSA)
Key count	One shared key	Public + private key pair
Speed	Very fast, suits bulk data	Slow, suits key exchange + signatures
Main use	Disk encryption, DB encryption, file encryption	TLS handshake, code signing, JWT signing
Key distribution risk	High — sharing the key is the hard problem	Low — public key is freely distributable
Indian regulatory fit	Required for data at rest (RBI, DPDP)	Required for TLS/HTTPS (PCI-DSS, RBI)

How TLS Protects Data in Transit

When a browser connects to https://yourapp.com, TLS (Transport Layer Security) runs a handshake that does three things: authenticates the server via its certificate, negotiates a shared session key using asymmetric cryptography, and then encrypts all subsequent traffic with that session key using a symmetric cipher (typically AES-256-GCM).

Every API call between your frontend and backend, between microservices, and between your app and third-party payment gateways must travel over TLS 1.2 at minimum. TLS 1.3 is preferred — it is faster and removes weaker cipher suites. HTTP (unencrypted) is unacceptable for any surface that handles user data.

⚠️

WARNING

Disabling TLS certificate verification in production code (verify=False in Python, rejectUnauthorized: false in Node.js) to "fix" a certificate error is equivalent to turning off encryption entirely for that connection. An attacker on the same network can intercept all traffic. Fix the certificate; never suppress the check.

Common TLS mistakes that Indian engineering teams make:

Using self-signed certificates on internal APIs without pinning
Allowing TLS 1.0 and 1.1 on legacy servers (both are broken and banned under PCI-DSS 4.0)
Forgetting to encrypt inter-service traffic inside a private VPC (traffic within a VPC is not encrypted by default)
Using expired certificates that cause browsers to show security warnings, training users to click through them

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

Encryption at Rest: Disk, Database, and Field Level

"Encryption at rest" is not a single switch — it operates at three layers, each with different trade-offs.

Disk-Level Encryption

Full-disk encryption (FDE) protects data if the physical media is removed. AWS EC2 EBS volumes, RDS instances, and S3 buckets all support AES-256 encryption with a checkbox. This costs nearly nothing and should be non-negotiable for every production workload. It does not protect against a compromised running application — if your app is breached, the OS has already decrypted the disk.

Database-Level Encryption (TDE)

Transparent Data Encryption (TDE) encrypts the database files on disk. PostgreSQL and MySQL support it natively; managed services like AWS RDS and Azure SQL enable it by default. Again, this protects against storage theft but not against SQL injection or compromised app credentials — the DB engine decrypts data transparently for any authenticated connection.

Field-Level Encryption

Field-level encryption (FLE) encrypts individual columns before they reach the database. The application encrypts sensitive values (Aadhaar numbers, PAN, bank account numbers, health data) using a key that the database server never sees. Even a DBA with full DB access cannot read the plaintext values. This is the strongest form of protection and is required under DPDP for sensitive personal data categories.

A practical pattern: store Aadhaar as AES-256-GCM(aadhaar_number, kms_key) in the column. The KMS key is managed by AWS KMS or Google Cloud KMS — your application fetches a data encryption key (DEK) per record, uses it to encrypt, and discards it from memory. The DEK itself is stored encrypted under a Key Encryption Key (KEK) managed by the KMS.

Key Management: The Part Most Teams Skip

Encryption without key management is theater. If your encryption key lives in a .env file next to the code it protects, or is committed to a git repository, the encryption provides no meaningful protection.

Use a dedicated KMS. AWS KMS, Google Cloud KMS, Azure Key Vault, and HashiCorp Vault all provide hardware-backed key storage, audit logs of every key usage, and automatic key rotation. Keys never leave the KMS in plaintext — your application asks the KMS to encrypt or decrypt, and the KMS returns the result without exposing the raw key.

Key rotation. Rotate your data encryption keys at least annually, and rotate immediately after any suspected compromise. A good KMS automates this. Without rotation, a leaked key compromises every record encrypted under it — past and future.

Separation of duties. The engineer who writes code that uses encryption keys should not also be the person who manages the keys. Production key access should require explicit IAM policies, not be granted by default.

🛡️

SECURITY

Never hardcode encryption keys, API secrets, or database passwords in source code. Use environment variables injected at runtime from a secrets manager (AWS Secrets Manager, HashiCorp Vault). Rotate any key that has ever appeared in a git commit — treat it as permanently compromised.

Hashing Is Not Encryption: Passwords and bcrypt/argon2

Hashing and encryption are different operations. Encryption is reversible (you can decrypt back to plaintext with the key). Hashing is a one-way function — you cannot recover the original input from the hash.

Passwords must be hashed, not encrypted. If you encrypt a password, anyone who obtains the encryption key can decrypt every password in the database. If you hash with a strong algorithm, even with the database dump, an attacker cannot recover the passwords without brute-forcing each one.

The correct algorithms for password hashing are bcrypt (work factor 12+) or argon2id (minimum: memory 19 MiB, iterations 2, parallelism 1 — per OWASP Password Storage Cheat Sheet). MD5 and SHA-1 are not password hashing algorithms — they are cryptographic hash functions designed for speed, which makes them trivially brute-forceable on modern GPUs. SHA-256 without a salt is similarly broken for passwords.

A simple rule: if your user table has a password column that does not contain a bcrypt or argon2 hash string starting with $2b$ or $argon2id$ , your password storage is insecure.

Where Encryption Applies: The Full Data Flow

The diagram below maps every point where encryption should be applied in a typical Indian SaaS architecture.

graph TD
    A[User Browser] -->|TLS 1.3 HTTPS| B[Load Balancer / CDN]
    B -->|TLS internal| C[App Server]
    C -->|TLS| D[Database]
    C -->|TLS| E[Payment Gateway]
    C -->|TLS + S3 SSE| F[Object Storage S3]
    D -->|AES-256 TDE| G[Encrypted DB Files on Disk]
    C -->|Field-Level Encryption via KMS| H[Sensitive Columns - Aadhaar - PAN - Bank Account]
    C -->|bcrypt - argon2id| I[Password Hash Column]
    F -->|AES-256 SSE| J[Encrypted Files at Rest]
    K[KMS] -->|DEK wrapped under KEK| C

    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style D fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style F fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style G fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style H fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style I fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style J fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style K fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

pie title Where Indian SaaS Applications Fail Encryption Checks
    "No TLS on internal APIs" : 38
    "Plaintext passwords or MD5" : 27
    "No encryption at rest on DB" : 19
    "Keys hardcoded in source" : 11
    "Expired or self-signed certs" : 5

ℹ️

NOTE

The pie chart above reflects VAPT findings patterns observed across automated assessments. NIST SP 800-111 (Storage Encryption of End User Devices) and NIST SP 800-52 Rev 2 (TLS Guidelines) provide the authoritative technical baseline that these categories map to. See NIST SP 800-52 for TLS configuration guidance.

Common Encryption Mistakes Indian Teams Make

Encrypting the wrong thing. Teams often encrypt the database at the storage layer (TDE) and consider the job done. They miss field-level encryption for the high-sensitivity columns that regulators actually care about.

Using ECB mode for AES. AES-ECB encrypts each block independently, which means identical plaintext blocks produce identical ciphertext blocks — patterns are preserved. Always use AES-GCM or AES-CBC with a random IV. Your crypto library defaults should handle this, but verify.

Reusing IVs or nonces. Initialization vectors must be random and unique per encryption operation. Reusing an IV with AES-GCM can catastrophically break the encryption's confidentiality. Use a cryptographically secure random number generator (CSPRNG) to generate IVs.

No key rotation process. Many teams generate a key at launch and never rotate it. When a developer leaves the company or a system is compromised, that key remains active indefinitely.

Logging sensitive data before encryption. A common mistake is logging the plaintext value of a sensitive field for debugging purposes, then encrypting it for storage. The log files become an unencrypted copy of the data you encrypted.

How Encryption Maps to DPDP, RBI, and PCI Requirements

The DPDP Act 2023 does not specify an encryption algorithm — it requires "reasonable security safeguards." What constitutes reasonable is interpreted by reference to established standards. MeitY's guidance cites ISO 27001 and NIST controls. Concretely: AES-256 for data at rest, TLS 1.2+ in transit, and bcrypt/argon2 for passwords will satisfy the technical baseline.

RBI's Master Direction on IT and Cyber Security (2023) is more prescriptive for regulated entities. It requires encryption of all sensitive customer data in transit and at rest, key management procedures with defined rotation periods, and HSM or KMS-backed key storage for financial institutions.

PCI-DSS 4.0 (effective April 2024) mandates TLS 1.2+ for all cardholder data transmissions, strong cryptography for stored PANs, and documented key-management procedures including custodian accountability.

A free VAPT scan will surface unencrypted data stores, weak TLS configurations, and hardcoded keys automatically — the same findings that auditors will flag during compliance reviews. Bachao.AI, built by Dhisattva AI Pvt Ltd, maps every finding to the relevant regulatory control so you know exactly which gap corresponds to which requirement.

For a detailed look at your DPDP compliance posture beyond encryption, see /dpdp-compliance.

Encryption Implementation Checklist

Control	Standard	Status Check
TLS 1.2+ on all external endpoints	PCI-DSS 4.0, RBI	Verify with SSL Labs or automated scan
TLS on all internal service-to-service calls	NIST SP 800-52	Check service mesh / nginx configs
EBS / RDS / S3 encryption enabled	AWS baseline	Check via AWS Config rule
TDE enabled on database	DPDP, RBI	Check DB configuration
Field-level encryption for Aadhaar, PAN, bank data	DPDP, RBI	Code review + VAPT
Passwords hashed with bcrypt/argon2	OWASP, NIST	Check hash format in DB
No keys in source code or `.env` committed to git	NIST SP 800-57	git-secrets scan
KMS or Vault for key storage	NIST SP 800-57	Infrastructure audit
Annual key rotation schedule	RBI, PCI-DSS	Policy document + KMS rotation config
IV/nonce uniqueness enforced	NIST	Code review

🎯Key Takeaway

Encryption is not one switch — it is a layered stack. TLS for transit, AES-256 for storage, field-level encryption for the most sensitive columns, bcrypt/argon2 for passwords, and a KMS for every key. Miss one layer and the others can be bypassed. The most common real-world failures are not broken algorithms — they are hardcoded keys, missing field-level encryption, and plaintext passwords.

Frequently Asked Questions

Is TLS enough to satisfy the DPDP Act's encryption requirement?

TLS protects data in transit, but the DPDP Act requires protection for personal data at rest as well. You need both TLS for transit and AES-256 encryption for stored personal data. Field-level encryption is particularly important for sensitive categories like Aadhaar, health data, and financial records.

What is the difference between hashing and encryption for passwords?

Encryption is reversible — anyone with the key can recover the original password. Hashing is one-way — you cannot reverse a hash to get the original value. Passwords should always be hashed (bcrypt or argon2id), never encrypted. If an attacker obtains your database and the encryption key, all encrypted passwords are immediately exposed.

Do I need encryption if my database is inside a private VPC?

Yes. Network isolation reduces attack surface but does not replace encryption. A compromised application server inside the VPC, a misconfigured security group, or an insider threat can all result in database access. Encryption at rest protects data even when the attacker has database-level access via stolen credentials.

Can I use MD5 or SHA-256 to hash passwords?

No. MD5 and SHA-256 are general-purpose hash functions designed for speed, which makes them trivially brute-forceable. Modern GPUs can test billions of MD5 hashes per second. Use bcrypt with a work factor of 12 or higher, or argon2id with OWASP-recommended parameters.

What does "key rotation" mean in practice?

Key rotation means replacing the encryption key used to encrypt your data with a new key on a defined schedule (typically annually) or immediately after a suspected compromise. A KMS like AWS KMS or HashiCorp Vault automates this — it re-encrypts your data encryption keys under the new key encryption key without requiring you to decrypt and re-encrypt every record manually.

Is field-level encryption required under Indian law or only recommended?

The DPDP Act 2023 requires "reasonable security safeguards" without specifying field-level encryption by name. However, for sensitive personal data categories — financial data, health records, biometrics — field-level encryption is considered the technical baseline by NIST and is specifically called out in RBI guidance for financial institutions. For any regulated entity or business handling such data, treating it as required is the defensible position.