Scrutora
The ₹250 Crore Line in Your Code
India's Digital Personal Data Protection Act (DPDPA) is no longer a draft, a proposal, or something to worry about “later.” The DPDP Rules were finalized in November 2025. Phase 2 enforcement hits November 2026. Full enforcement arrives May 2027. Penalties go up to ₹250 crore.
The highest penalty under DPDPA — ₹250 crore (approximately $30 million) — applies to organizations that fail to implement “reasonable security safeguards” under Section 8(5). Here's what most developers miss: this penalty can be triggered even if no actual data breach occurs. The mere failure to have adequate security measures is sufficient.
Critical: If your application stores patient records in an unencrypted database, logs patient names and diagnoses to stdout, or passes personal data to a third-party API without proper safeguards, you're already in violation territory — whether or not anyone has been hacked.
For healthcare developers specifically, this creates a new reality: the code you ship is now auditable evidence of compliance or non-compliance.
DPDPA Is Not GDPR with Indian Characteristics
If you've worked with GDPR, you might assume DPDPA is similar. It's not. Several differences matter for developers:
No Distinction Between Personal and Sensitive Data
GDPR treats health data as a special category with extra protections. DPDPA treats all personal data the same under Section 2(t), defined as “any data about an individual who is identifiable by or in relation to such data.” This means every field that could identify a patient — including their name, phone number, address, or Aadhaar number — carries the same weight as their diagnosis or lab results. You can't have a “less protected” tier in your application.
Consent Is the Primary Legal Basis
While GDPR offers six legal bases for processing (consent, legitimate interest, contractual necessity, etc.), DPDPA is a consent-first framework. Under Section 4, a Data Fiduciary may process personal data only with the Data Principal's consent or for “certain legitimate uses.” For healthcare, this means you need explicit, verifiable consent mechanisms built into your application before processing any patient data. The “we need it to provide care” argument has a much narrower scope than GDPR's legitimate interest.
Itemized, Not Categorical, Privacy Notices
GDPR requires you to list categories of data and categories of third parties. DPDPA requires an itemized list of specific data types collected and the identities of all data fiduciaries and processors who receive that data. If your app collects a patient's name, phone, Aadhaar, blood group, and diagnosis, your notice must list each one individually. If you share data with a lab partner, a cloud provider, and an analytics service, you must name each one specifically.
Data Must Be Deleted the Moment Its Purpose Ends
Under Rule 8, retention is tied strictly to purpose. The moment data is no longer needed for the stated purpose, it must be erased. For healthcare, where records often need long retention, you must define and enforce specific retention periods in your code — not just your policy documents.
What This Means for Your Codebase
Here are the DPDPA requirements mapped to actual code-level changes Indian healthcare developers need to make.
1. Encryption at Rest Is Non-Negotiable
Section 8(3) requires “reasonable security safeguards.” In 2026, storing patient data in plaintext databases does not meet any reasonable definition of adequate safeguards. This applies to:
- Your primary database (PostgreSQL, MongoDB, MySQL)
- Cache layers (Redis, Memcached) if they hold patient data
- File storage (S3, local filesystem) for documents, images, reports
- Search indices (Elasticsearch, OpenSearch) if they index patient fields
- Backup files and exports
If you're using Prisma, Sequelize, Django ORM, or any other ORM layer, check whether your patient-facing models encrypt sensitive fields at the application layer, or whether you're relying solely on database-level encryption. Both layers matter.
2. PHI in Logs Is a Violation Waiting to Happen
Consider this common pattern in error handling:
logger.error(f"Failed to process patient: {patient.name}, ID: {patient.id}, diagnosis: {patient.diagnosis}")Under DPDPA, this is a problem. You're writing personal data to logs that may be shipped to third-party logging services (Datadog, CloudWatch, Grafana Cloud). Those services may or may not have servers in India. Even if they do, you've now shared personal data with a third party without the itemized disclosure DPDPA requires.
logger.error(f"Failed to process patient: record_id={patient.record_id}")Audit every logger.info(), logger.error(), console.log(), and print() statement in your codebase. If patient data appears in any of them, it needs to be redacted.
3. Consent Must Be Verified in Code, Not Just Policy
DPDPA Section 6 requires “free, specific, informed, unconditional, and unambiguous” consent. For healthcare applications, this means:
- Your patient registration flow must capture granular consent before storing any data
- Consent must be withdrawable at any time, and your application must actually stop processing when consent is withdrawn
- If you process data for multiple purposes (treatment, billing, research, analytics), each purpose needs separate consent
- You must record when consent was given, for what purpose, and make that record available to the patient on request
This isn't a policy checkbox. It's an architectural requirement. If your data processing pipeline doesn't check consent status before accessing patient records, you have a code-level compliance gap.
4. Cross-Border Data Transfer Restrictions
DPDPA Section 16 restricts transfer of personal data outside India to countries notified by the Central Government. For healthcare developers, this affects:
- Cloud infrastructure: Is your AWS/Azure/GCP region in India? Are backups replicated to regions outside India?
- Third-party APIs: If you're calling an international lab API, payment gateway, or AI service, patient data is leaving India
- SaaS tools: Your CRM, analytics, email, and support tools may process patient data outside India
- AI/ML services: If you're sending patient data to OpenAI, Claude, or any hosted model outside India, that's a cross-border transfer
You need a data flow map showing exactly where patient data goes, including every third-party service. If any destination is outside India (or outside notified countries), you need to either find an Indian alternative or implement technical safeguards to anonymize the data before it leaves.
5. Right to Erasure Must Work — Actually Work
When a patient withdraws consent or requests deletion under Section 8(7), your application must actually delete their data from:
- Primary database
- All replicas and read replicas
- Cache layers
- Search indices
- Backup files (this is the hard one)
- Third-party systems you've shared data with
- Log files (if they contain personal data)
A soft delete flag in your users table does not constitute erasure. Automated retention schedules and cascading deletion pipelines are now engineering requirements, not nice-to-haves.
6. Purpose Limitation in API Design
DPDPA Section 4(2) limits data processing to the stated purpose. For API developers, this means:
SELECT *queries on patient tables violate the purpose limitation principle by fetching more data than needed- API responses that return full patient objects when only a name and appointment time are needed
- Internal microservices that pass complete patient records between services when only an ID is required
Data minimization is now a code-level requirement. Your APIs should return only the fields necessary for the requesting function.
The Enforcement Timeline You Need to Plan Around
The enforcement is phased, but the deadlines are firm:
Phase 1 — November 2025 (Already Active)
The law exists. The Data Protection Board of India is established. Organizations should already be developing their data privacy frameworks.
Phase 2 — By November 2026
Breach response procedures must be operational. Privacy training programs must be established. Annual data protection impact assessments and independent audits begin. This is 8 months away.
Phase 3 — May 2027
Full enforcement. Penalties of up to ₹250 crore become active. All compliance mechanisms must be fully operational.
If you're starting compliance work now, you have roughly 14 months until full enforcement. That sounds like a lot, but consider what “compliance” actually requires: mapping every data flow in your application, implementing consent management, building deletion pipelines, encrypting storage, remediating log outputs, establishing audit trails, documenting everything, and training your team.
Healthcare Gets Special Attention
DPDPA applies to all sectors, but healthcare organizations processing health data at scale are likely candidates for designation as “Significant Data Fiduciaries” (SDF) under Section 10. India has not yet designated specific SDFs, but it is expected to do so in 2026.
SDF designation brings additional obligations including mandatory appointment of a Data Protection Officer, annual data protection impact assessments, independent annual audits, and potential data localization requirements. For large hospital chains, health insurance companies, and health-tech platforms, SDF designation should be treated as a certainty for planning purposes.
The DPDP Rules reference healthcare-specific definitions from the Clinical Establishments Act 2010, the National Commission for Allied and Healthcare Professions Act 2021, and the Mental Healthcare Act 2017. This cross-referencing signals that healthcare will receive focused regulatory attention.
What Indian Healthcare Developers Should Do This Week
Start with these concrete actions:
Map Your Data Flows
Document every place patient data enters your system, where it's processed, where it's stored, and where it leaves your system boundary. Include every third-party service, every API call, every log destination. You cannot comply with a law about data protection if you don't know where your data goes.
Audit Your Logs
Search your codebase for every logging statement. If patient names, Aadhaar numbers, phone numbers, addresses, diagnoses, or any other personal data appears in any log output, fix it immediately. This is the lowest-effort, highest-impact change you can make today.
Check Your Encryption
Verify that your database has encryption at rest enabled at the infrastructure level. Then check whether your application layer adds field-level encryption for sensitive fields. Both matter.
Review Your Consent Flow
Does your application capture explicit consent before processing patient data? Is that consent granular (per-purpose)? Can a patient withdraw consent and have processing actually stop? If any answer is “no,” you have architectural work to do.
Inventory Your Third-Party Services
List every SaaS tool, API, and cloud service that touches patient data. For each one, determine: where are their servers? Do they have a presence in India? Is there a Data Processing Agreement in place? This inventory will be required for your privacy notice.
The Bottom Line
DPDPA is not HIPAA. There's no safe harbor for “reasonable efforts” after a breach. There's no addressable vs. required distinction. The penalties are absolute — up to ₹250 crore — and they apply to the failure to have safeguards, not just to actual breaches.
For Indian healthcare developers, the message is clear: compliance is no longer a policy exercise handled by your legal team. It's an engineering requirement embedded in every line of code that touches personal data.
The organizations that treat DPDPA as a code-level problem — and start remediating now — will be ready for May 2027. The rest will be scrambling.