For years, enterprise security has focused on protecting where data is stored and how it moves.
Encryption protects databases. TLS protects data in transit. Access controls determine who can access systems. Monitoring helps detect suspicious activity.
But modern applications do something traditional security architectures find harder to protect: they use the data.
Customer MDM platforms match records. Fraud engines analyse transactions. AML systems screen names. Analytics platforms query customer profiles.
This creates a critical question for IT teams:
How do you protect sensitive data while applications are processing it?
That is the problem secure data processing aims to address, particularly through Privacy Enhancing Technologies (PETs) that allow operations to be performed while reducing exposure of raw personal data.
Why secure data processing matters now
India's data protection landscape has evolved significantly with the notification of the Digital Personal Data Protection Rules, 2025.
The Rules require Data Fiduciaries to implement reasonable security safeguards, including measures such as encryption, obfuscation, masking or virtual tokens, access controls, logging and monitoring, backups, contractual safeguards for Data Processors, and appropriate technical and organisational measures.
For IT teams, this has a practical implication: data protection is an architecture problem.
Where personal data is stored, how it moves between systems, which applications can access it, where it is decrypted, and how third parties process it all matter.
DPDP Act has significant financial penalties, including penalties of up to ₹250 crore for certain contraventions relating to reasonable security safeguards.
Step1: Understand the three states of data
A useful starting point is to map sensitive data across three states.
1. Data at rest
Data at rest is personal information stored in databases, data lakes, backups, file systems and cloud storage. Encryption is a foundational control here. If an attacker obtains an encrypted database without the necessary keys, the stored information remains difficult to interpret.
Primary controls: encryption, key management, database security, access controls.
2. Data in transit
This is PII moving between systems. Think: core banking to MDM, applications to analytics platforms, customer applications to backend services or enterprise systems to third-party processors.
For regulated financial entities, secure data transmission and third-party risk management are already established areas of IT governance. RBI's IT Governance Directions specifically require controls for the secure storage, transmission and processing of data and information, while its IT outsourcing directions address customer-data confidentiality and integrity when third parties are involved. .
Primary controls: TLS, secure APIs, network controls, encryption.
3. Data in use
This is where the architecture becomes more challenging. PII is queried, matched, deduplicated, screened, analyzed, enriched, or used to make a decision.
For example, a customer MDM platform may need to compare two customer names and dates of birth. An AML platform may need to screen a customer's name. A fraud system may need to correlate identities across datasets.
Traditional encryption generally requires data to be decrypted before conventional applications can perform these operations. This creates the data-in-use exposure gap. The important question for IT teams is therefore:
Where does plaintext PII exist while our applications are working with it?
Step 2: Build a layered security architecture
A stronger architecture is layered
Secure data processing should not mean abandoning conventional security. Encryption remains foundational. IT teams should not treat Privacy Enhancing Technologies (PET) as a replacement for it. But it is not enough.
Standard technical safeguards often focus on encryption at rest (AES-256 for databases) and encryption in transit (TLS 1.2+ for HTTPS). But data must be turned back into plaintext the moment it needs to be used for matching, deduplication, or analytics. That means sensitive information is still exposed to:
- Application processes
- Administrators
- Data stewards
- Third-party processors
- Analytics environments
- Integration layers
Once you identify where sensitive data is exposed during processing and select the appropriate privacy enhancing technology for that workload.
Searchable Encryption is one example of a PET that can support search and matching operations on protected data.
CONVENTIONAL WORKFLOW
Customer record → decrypt → plaintext → search/match
PROTECTED WORKFLOW
Customer record → tokenized → search/match → result
Step 3: Create a practical secure data processing checklist
Before selecting a technology, IT teams should answer seven questions.
- Where does PII exist?
Compliance is impossible if you do not know where your data lives. IT administrators must build a system to map every category of personal data collected, its purpose, and its storage location.
2. Where is PII decrypted?
This often reveals the most important exposure points. Identify the systems, applications, administrators and environments that can access plaintext.
3. Which operations need to happen on sensitive data?
Identify whether the workload involves searching, matching, deduplication, screening, analytics or another operation.
4. Can those operations happen on protected data?
Evaluate PETs according to the specific workload.
5. What happens when data leaves your environment?
Review APIs, cloud environments, SaaS platforms, Data Processors and other integrations.
6. Can you demonstrate the control?
Security architecture should be observable through logs, policies, technical controls, and audit evidence.
Step 4: Strengthen access controls
Protecting data during processing does not eliminate the need for basic security hygiene.
- Enforce Least-Privilege Access
Use Role-Based Access Control (RBAC) and the Principle of Least Privilege (PoLP). Users and applications should receive only the access necessary for their specific role or function. Regularly review privileged access and remove permissions that are no longer required.
- Operationalise Retention and Deletion
Data should not be retained indefinitely simply because storage is inexpensive. Build retention requirements into application and data architecture, including:
- Automated deletion or anonymisation where appropriate
- Retention policies for databases and archives
- Backup and recovery policies
- Controls for expired or obsolete data
Retention requirements should also account for specific legal or regulatory obligations rather than relying on a blanket deletion rule.
Step 5: Secure third-party and cloud integrations
A secure architecture does not stop at the organisation's network boundary. Because Data Fiduciary (the organization that decides how data is used) remains legally accountable even if a Data Processor (a third-party vendor) mishandles the data.
Map where personal data is processed by:
- Cloud providers
- SaaS platforms
- Analytics providers
- Screening services
- MDM platforms
- Other Data Processors
Review their access controls, security practices, contractual obligations, processing locations and incident-management processes.
Secure data processing: the takeaway
For IT teams, the practical takeaway is straightforward: Encrypt what you store. Secure what you transmit. Control who can access it. And examine how you protect PII while applications are actually using it.
That last layer is where Privacy Enhancing Technologies can make the biggest architectural difference. The goal is not to make data unusable. It is to make sensitive data usable without exposing it.
