How application developers can adopt privacy-by-design principles, strengthen data security, and prepare their applications for India’s Digital Personal Data Protection framework.

India’s Digital Personal Data Protection (DPDP) Act, 2023, introduces a framework for protecting digital personal data and establishing accountability for organisations that process it. With the DPDP Rules, 2025, now notified and implementation being phased in, organisations have an opportunity to review their existing applications and address data privacy risks before the relevant compliance obligations take effect.

However, DPDP compliance is not something an external testing or certification agency can simply deliver. It requires a combination of organisational policies, operational processes, and technical safeguards that work together to protect personal data.

For organisations delivering services through software applications, this presents a particular challenge. Applications often collect and process personal data on behalf of customers, yet many were designed without privacy-by-design principles in mind. Over time, additional features, integrations, and data collection requirements can increase the amount of personal data stored, the number of people who can access it, and the potential impact of a security breach.

The good news is that many improvements can be implemented directly at the application architecture and design levels.

This article outlines 11 practical measures application developers can adopt to reduce data privacy risks and prepare their applications for the DPDP framework.

1. Minimise the Personal Data You Collect

The simplest way to reduce the impact of a data breach is to collect less personal data in the first place.

Application developers should begin by reviewing every personal data field collected, stored, or processed by their applications. For each field, document:

• Why the data is required.
• Which application feature or business process depends on it.
• Whether the same functionality can be delivered without collecting it.
• Who needs access to the data.
• How long the data needs to be retained.

Convert this review into a formal data collection policy, approved by the relevant business and technical stakeholders.

Implement the policy in the application by making only essential fields mandatory and collecting additional information only when there is a justified requirement. Version the policy whenever requirements change, and ensure that application changes remain aligned with the approved policy.

How EHR.Network helps

EHR.Network has been designed to support application development with minimal mandatory data requirements. This allows application developers to determine what personal data they need to collect and manage, rather than having unnecessary data collection imposed by the underlying platform.

2. Apply the Principle of Least Privilege

Not every user, application component, or service needs access to all the data in a system.

Excessive permissions increase the risk of accidental disclosure, misuse of privileges, and unauthorised access when an account or service is compromised.

Start by preparing a data access policy that identifies which users, roles, and services require access to specific resources. Review existing permissions against actual service delivery requirements.

Implement role-based access control and, where appropriate, finer-grained permissions based on the resource, organisation, or operational context.

Access policies should be reviewed periodically and whenever user responsibilities change. Changes to these policies should be versioned and auditable.

How EHR.Network helps

EHR.Network provides a configurable authentication and authorisation framework that allows applications to implement access controls aligned with their access policies.

Developers can use these capabilities to manage permissions without having to build an entirely separate access control system for every application.

3. Design Audit Logging Without Exposing Personal Data

Logs are essential for security monitoring, troubleshooting, and forensic investigations. However, they can also become an overlooked source of personal data leakage.

Applications frequently log request parameters, response payloads, identifiers, authentication details, and error messages. These logs may then be copied into monitoring systems, exported to support teams, or retained for longer than the underlying application data.

Developers should implement logging at common interfaces, such as API gateways and shared middleware, wherever possible.

A well-designed logging strategy should:

• Record who accessed a resource, when the access occurred, and which operation was performed.
• Capture the outcome of requests and relevant security events.
• Avoid logging personal data, access tokens, passwords, and sensitive request or response payloads.
• Apply access controls and retention policies to logs.
• Support structured formats that can be processed by monitoring and reporting tools.

Raw operational logs and security audit records should be designed for their respective purposes, with appropriate retention and access controls. Tools such as Graylog and OpenSearch can help analyse logs and generate reports.

How EHR.Network helps

EHR.Network supports configurable gateway-level logging. This allows applications to generate structured logs suited to their monitoring and audit requirements while minimising the exposure of personal data.

Its JSON-based logging also makes the resulting records easier to process and can help reduce the storage overhead associated with long-term retention.

4. Separate Primary Service Delivery from Secondary Data Use

Personal data collected to deliver a service may later appear useful for analytics, research, cohort management, clinical decision support, or other secondary purposes.

These uses should not automatically inherit the permissions or consent arrangements associated with the original service.

For each proposed use, developers and business stakeholders should establish:

• The specific purpose of processing.
• The personal data required for that purpose.
• The applicable lawful basis for processing.
• Whether consent is required and, if so, whether the available consent covers the intended use.
• How access will be restricted to the data needed for that purpose.

Where appropriate, implement secondary-use applications or services separately from the primary service delivery system. This separation makes it easier to enforce distinct access controls, purpose restrictions, and data minimisation requirements.

Avoid treating a broad, generic consent as permission for every future use. The applicable requirements depend on the purpose and legal basis of the processing.

How EHR.Network helps

EHR.Network provides FHIR R4-based consent resources that applications can use to represent and manage consent arrangements for different purposes.

This provides a foundation for implementing use-case-specific consent management and integrating consent checks into secondary applications and workflows.

5. Separate Personal Data at the Persistence Layer

Application-level access controls are important, but they should not be the only barrier protecting personal data.

If multiple categories of information are stored together, a compromised database account or exposed database may provide access to a much larger collection of information than an attacker initially needs.

Consider separating data into independently protected persistence systems based on its function, sensitivity, and access requirements.

For example, demographic information, clinical records, financial information, and operational data may have different access patterns and security requirements.

Where feasible:

• Use separate databases or storage boundaries for different data categories.
• Apply independent database credentials and least-privilege permissions.
• Restrict connectivity between persistence systems.
• Keep identifiers used across systems appropriately separated.
• Avoid unnecessary aggregation of data through shared service accounts or administrative interfaces.

Separation does not eliminate the risk of a breach, but it can reduce the amount of data exposed when an individual component is compromised.

How EHR.Network helps

EHR.Network separates patient demographics managed through its FHIR services from clinical records managed through its openEHR services.

The two services use separate identifiers for their respective records. This architectural separation provides an additional layer of protection against direct aggregation of patient information following a breach of a single data store.

Applications must still enforce appropriate access controls when linking these records for legitimate service delivery.

6. Encrypt Personal Data at the Application Level Where Appropriate

Encryption is a critical security measure, but it should be implemented with a clear understanding of the threats it is intended to address.

Transport encryption protects data in transit, while database or disk encryption helps protect stored data against certain forms of infrastructure exposure. Neither necessarily prevents someone with legitimate access to an application or database from reading the data.

For particularly sensitive fields, consider application-level encryption before data is persisted.

A secure implementation should include:

• Well-established, authenticated encryption algorithms.
• Secure key generation and storage.
• Separation of encryption keys from the data they protect.
• Key rotation and revocation procedures.
• Access controls governing which application components can decrypt data.
• A documented recovery process.

Do not implement a custom encryption algorithm or use reversible encoding or hashing interchangeably with encryption. Hashing is generally one-way; it cannot be used to recover the original value. For recoverable personal data, use an appropriate encryption scheme.

Application-level encryption can reduce exposure if an attacker gains access to stored ciphertext without also obtaining the relevant decryption keys. However, it may limit searching, indexing, and processing of encrypted fields, so the design should reflect the application’s functional requirements.

How EHR.Network helps

EHR.Network supports string-based storage in many personal data fields, allowing applications to encrypt selected values before persisting them.

This gives developers flexibility to manage encryption keys within their own security architecture. The fields selected for encryption and the resulting application behaviour must be designed and tested carefully.

7. Enforce Consent at the Point of Access

Recording consent in a database is not enough. An application must also ensure that the recorded consent is respected when personal data is accessed or processed.

A consent enforcement point (CEP) can perform this check before a request reaches the backend service.

For applications that require contextual consent enforcement, the CEP can evaluate relevant information such as:

• The identity and role of the requesting user or service.
• The individual whose data is being accessed.
• The intended purpose of processing.
• The type of data requested.
• The applicable consent status and scope.
• Any relevant restrictions or expiry conditions.

The enforcement point should deny or appropriately restrict requests that do not satisfy the applicable policy.

Implementing this as an edge service or shared middleware component can help ensure that consent checks are applied consistently across multiple application endpoints.

However, a CEP must be designed to interpret consent in the context of the applicable legal basis and processing purpose. A consent check alone cannot establish that every processing operation is lawful.

How EHR.Network helps

EHR.Network provides search capabilities for its consent resources, allowing applications to retrieve consent information and implement context-aware consent enforcement.

Developers can use these capabilities to build a CEP that evaluates relevant consent information before forwarding requests to backend services.

8. Implement Consent Lifecycle Management and Versioning

Consent is not a one-time event. It may need to be updated, withdrawn, superseded, or reviewed as the purposes of processing change.

A robust consent management system should maintain a record of the consent applicable to a particular processing activity and preserve the history needed to demonstrate how consent was managed.

Important considerations include:

• Recording the relevant consent terms and purposes.
• Maintaining the status and scope of consent.
• Recording when consent was obtained or changed.
• Supporting withdrawal and subsequent enforcement.
• Retaining appropriate evidence of the consent interaction.
• Recording relevant changes in an auditable history.

Use a suitable consent data model, such as the FHIR Consent resource, or an appropriate third-party consent management service.

Where applicable, FHIR Provenance can help record information about how consent resources were created or changed. Additional audit records may be necessary to capture the actual interaction through which consent was obtained.

Consent withdrawal must also be reflected in downstream processing systems. Simply changing a record in the consent database is insufficient if other services continue processing data under the withdrawn consent.

How EHR.Network helps

EHR.Network versions its consent resources, helping applications maintain a history of consent changes. It also exposes FHIR Provenance resources that applications can use to support the required audit trail.

Together, these capabilities provide a foundation for implementing consent lifecycle management and integrating consent records with application-level enforcement.

9. Implement Intrusion Detection and Prevention

Even a well-designed application can be compromised through vulnerabilities, stolen credentials, misconfigured infrastructure, or attacks against exposed APIs.

Developers should therefore implement security controls at the API gateway and backend levels.

A gateway can provide a common enforcement point for controls such as:

• Authentication and authorisation.
• Rate limiting and request throttling.
• IP-based restrictions where appropriate.
• Request validation.
• Web application firewall rules.
• Detection of suspicious access patterns.
• Security event logging and alerting.

These controls should complement, rather than replace, secure application development, timely patching, infrastructure hardening, and backend authorisation.

Security events should feed into a monitoring process that can detect unusual patterns, trigger alerts, and support incident investigation.

How EHR.Network helps

EHR.Network includes an integrated API gateway that supports centralised security policies and configurable logging.

This provides application developers with a common point for implementing security controls and monitoring API traffic, helping them identify suspicious activity before it results in a larger incident.

10. Prepare for Personal Data Breach Detection and Notification

A data breach response should not begin with an email drafted after an incident has already occurred.

Organisations should have a documented incident response process that defines how a suspected breach is detected, assessed, contained, investigated, and reported.

Application developers can support this process by building the necessary technical capabilities into their systems.

These should include:

• Monitoring and alerting for suspicious access.
• Identifying potentially affected users and records.
• Maintaining logs that support incident investigation.
• Recording the timeline and scope of an incident.
• Providing mechanisms to notify affected individuals.
• Supporting notification to the relevant authority in accordance with applicable requirements.
• Recording the actions taken during incident response.

Notifications should be triggered through a controlled workflow that considers the evidence available, the applicable notification requirements, and the information that can safely be communicated.

Automated notifications can reduce response time, but they should not replace incident assessment or the organisation’s responsibility to meet applicable notification obligations.

How EHR.Network helps

EHR.Network’s gateway-level access logs can support the identification and investigation of potentially affected records and access events.

Applications can integrate these logs with subscription and notification services to automate alerts for selected events, including suspected data breaches.

The organisation must still establish the incident response process, determine when notification is required, and ensure that notifications meet the applicable legal requirements.

11. Strengthen User Authentication

Not every security incident begins with a sophisticated technical exploit. Stolen passwords, phishing, automated login attempts, and compromised user accounts can provide attackers with legitimate-looking access to personal data.

Strong authentication is therefore an important part of privacy protection.

Application developers should consider:

• Enforcing appropriate password policies.
• Detecting and limiting brute-force login attempts.
• Supporting multi-factor authentication (MFA).
• Using OpenID Connect (OIDC) for federated authentication where appropriate.
• Configuring secure session management and token expiry.
• Protecting authentication and recovery workflows against social engineering.
• Applying additional authentication requirements to sensitive operations where justified.
• Reviewing and revoking access when users leave an organisation or change responsibilities.

Authentication establishes who is making a request; authorisation determines what that identity is permitted to do. Both are necessary.

Token expiry and MFA can reduce certain risks, but they should be complemented by appropriate token storage, session revocation, access controls, and monitoring.

How EHR.Network helps

EHR.Network includes an enterprise-grade authentication system built on Keycloak, supporting OAuth 2.0 and OpenID Connect.

Its capabilities include password policies, brute-force protection, multi-factor authentication, and integration with third-party identity providers such as Google and Microsoft.

These features allow applications to adopt established authentication mechanisms without building their own identity management system from scratch.

How These Measures Reduce DPDP Compliance Risks for Application Developers

The measures described above reinforce one another. Their combined value is greater than the benefit of implementing any single control in isolation.

1. Reduced data exposure

Data minimisation and functional separation reduce the volume of personal data available to an attacker when an application component or database is compromised.

2. Reduced risk of unauthorised access

Least-privilege permissions, strong authentication, and gateway-level controls make it harder for compromised accounts or malicious users to access information beyond their authorised scope.

3. Better breach investigation

Structured audit logs, consent versioning, and documented policies help establish what happened, which records may have been affected, and which controls were in place at the time.

4. Better support for individual rights

Well-designed consent management and audit systems can support workflows for responding to applicable requests concerning personal data, including access, correction, and erasure, subject to the relevant legal requirements.

5. More effective consent enforcement

A context-aware consent enforcement point can identify processing requests that do not match the applicable consent conditions and help prevent unauthorised use of personal data.

6. Reduced impact of infrastructure breaches

Separating data stores, restricting database privileges, and encrypting selected personal data can limit what an attacker can access or understand following a compromise.

7. Better control over secondary use

Purpose-specific access controls and separate processing workflows help prevent data collected for one service from being reused indiscriminately for other purposes.

8. Faster incident response

Monitoring, alerting, and notification mechanisms can help organisations identify incidents sooner, assess their impact, and respond in a structured manner.

A Practical Starting Point for Application Developers

Implementing all these measures at once may be difficult, particularly for organisations maintaining existing applications.

A practical starting point is to assess the current application against the following checklist.

Priority	Action	Expected outcome
1	Inventory personal data collected and stored	Identify unnecessary data collection and exposure
2	Document data collection and access policies	Establish clear, reviewable requirements
3	Review user roles and service permissions	Reduce excessive access privileges
4	Audit application and infrastructure logs	Identify and eliminate unnecessary personal data in logs
5	Map processing purposes and consent requirements	Improve control over how data is used
6	Review database architecture and encryption	Reduce the impact of infrastructure breaches
7	Implement consent enforcement where applicable	Prevent processing that violates applicable consent conditions
8	Introduce consent versioning and audit trails	Preserve evidence of consent management
9	Configure gateway security and monitoring	Improve protection and detection capabilities
10	Establish a breach response and notification workflow	Improve incident readiness
11	Strengthen authentication and session security	Reduce account compromise risks

Treat this as an ongoing engineering programme rather than a one-time compliance project. Assign owners, record implementation decisions, test controls, and revisit the assessment whenever the application or its processing purposes change.

Conclusion: Build Privacy into the Application Architecture

DPDP readiness requires more than a privacy policy or an external security assessment. It requires organisations to understand what personal data they process, why they process it, who can access it, and how they protect it throughout its lifecycle.

Application developers have a particularly important role because many privacy risks originate in architectural decisions: collecting unnecessary fields, granting excessive permissions, logging sensitive information, combining unrelated data stores, or allowing secondary uses without appropriate controls.

Addressing these issues at the application design level can reduce exposure, improve security, and make it easier for organisations to demonstrate that appropriate controls are in place.

Platforms that provide configurable access control, structured audit logging, consent management, data separation, and centralised API security can help developers implement these measures more consistently.

EHR.Network is designed to provide several of these capabilities as part of its interoperable healthcare data platform, helping application developers build privacy-conscious applications without having to implement every underlying capability independently.

The broader lesson is applicable beyond healthcare: the earlier privacy requirements are incorporated into application architecture, the easier they are to enforce, maintain, and demonstrate.

DPDP compliance remains an organisational responsibility. But with the right architectural choices, developers can make a substantial contribution to reducing risk and building applications that treat personal data protection as a fundamental design requirement.

📣 Building a DPDP-compliant healthtech application?

Talk to us about how EHR.Network can accelerate your compliance journey.

🔗 Learn more at ehr.network
📝 Get our help
📅 Book a call to discuss more