The legal framework: Section 8(5) and Rule 6
Section 8(5) states: “The Data Fiduciary shall protect personal data in its possession or under its control… by taking reasonable security safeguards to prevent personal data breach.” The word “reasonable” is contextual—what is reasonable for a small clinic differs from what is reasonable for a fintech platform processing millions of transactions.
Rule 6 adds that technical and organisational measures must be “appropriate to the nature and volume of personal data processed.” This creates a proportionality framework: higher-sensitivity data (health records, financial data, biometrics) and higher volumes demand stronger safeguards.
Encryption at rest: protecting stored personal data
Encryption at rest protects personal data stored in databases, file systems, backups and archives. The industry baseline is AES-256 (Advanced Encryption Standard, 256-bit key length)—widely supported by cloud providers (AWS KMS, Azure Key Vault, Google Cloud KMS) and database engines (PostgreSQL, MySQL TDE, MongoDB encryption).
- AES-256 for database-level encryption (transparent data encryption or column-level)
- Encrypted backups—unencrypted backup copies of encrypted databases defeat the purpose
- Key management: encryption keys stored separately from encrypted data, with access-controlled key rotation
- Full-disk encryption for employee devices that store or access personal data
- Encrypted archives for data retained under sector-specific mandates
Encryption in transit: protecting data in motion
Encryption in transit protects personal data moving between systems—browser to server, server to database, API to API. The baseline is TLS 1.2 or later (TLS 1.3 preferred). Older protocols (SSL 3.0, TLS 1.0, TLS 1.1) are deprecated and considered insecure.
- TLS 1.2+ for all HTTPS endpoints—no fallback to TLS 1.0/1.1
- Certificate management: valid certificates from trusted CAs, automated renewal
- Internal traffic: encrypt service-to-service communication (mTLS) for microservice architectures
- Email encryption: TLS for SMTP where personal data is transmitted by email
- API security: enforce HTTPS-only with HSTS headers; reject plaintext HTTP connections
Sector-specific encryption mandates
Several sector regulators impose encryption requirements that go beyond the DPDPA’s general “reasonable safeguards” standard:
| Regulator | Requirement | Scope |
|---|---|---|
| RBI | End-to-end encryption for UPI and digital payments | Payment transactions and card data |
| SEBI | Encryption of client data in trading systems | Broker and depository participant systems |
| CERT-In | Encryption recommended in cyber-security directives | All entities reporting to CERT-In |
| IRDAI | Encryption of policyholder data | Insurance companies and intermediaries |
| NABH | Encryption of patient health records | NABH-accredited healthcare facilities |
How AMLEGALS assists with encryption compliance
AMLEGALS is an Indian law firm. Its data privacy practice is led by Anandaday Misshra, Founder and Managing Partner, with Rohit Lalwani, Associate Partner, working on DPDPA compliance. The firm advises organisations on interpreting the “reasonable safeguards” standard, mapping encryption requirements across the DPDPA and sector-specific regulators, and designing security-safeguard frameworks that satisfy regulatory expectations.

