The DPDP Act has set off a major shift in how enterprises think about data governance. From your perspective, why does the compliance journey look so different for sectors like BFSI, healthcare, IT services and manufacturing?The DPDP Act regulates data itself, not just the systems that store it. That means every industry has to interpret the law through the lens of its own architecture, data flows and operating realities.

In BFSI, sensitive data is fragmented across core banking systems, loan platforms, partner apps and analytics pipelines, making purpose limitation and lineage hard to enforce at scale. Healthcare faces a different issue altogether — most hospital systems were never built for modern consent or erasure, and patient data exists across clinical systems, imaging archives and unstructured storage.

IT services and GCCs operate in shared, multi-tenant environments where client data moves across teams, geographies and systems, making purpose enforcement operationally complex. Manufacturing often lacks basic visibility, with personal data flowing between OT and IT systems and high-value IP moving across suppliers with limited controls.

So while the Act is uniform, the compliance journey isn’t. The real challenge is understanding what data exists, why it exists, where it moves and how it’s used — and those answers vary fundamentally by sector.

BFSI deals with deeply fragmented architectures where sensitive data sits across core banking systems, LOS, partner apps and analytics pipelines. What makes DPDP compliance especially challenging in this environment?BFSI environments generate continuous and often unstructured movement of personal and financial data across dozens of systems. That’s where compliance becomes complex.

Shadow data proliferates quickly. Borrower and KYC records frequently end up in export folders, BI tools, cloud buckets and vendor sandboxes. At the same time, enforcing purpose limitation is difficult — data collected for underwriting often gets reused for marketing, analytics or model training without clear consent trails.

Erasure is another major hurdle. The same customer record may exist across archival systems, disaster recovery sites, logs, dumps and analyst workbenches. Add to this the scale of partner ecosystems — fintechs, collection agencies and analytics vendors — and the risk multiplies.

Without deep semantic understanding of data and real-time enforcement, compliance becomes reactive and manual, which is exactly what BFSI leaders are trying to move away from.

Healthcare systems were never designed for modern consent workflows or data erasure. What practical barriers do hospitals face when trying to implement DPDP requirements?Hospitals operate in technology environments where clinical workflows take precedence over data lifecycle design. That creates several practical barriers. Most HIS and EHR systems lack native consent metadata, making it difficult to trace why a patient’s data was collected and for what purpose. Imaging systems like PACS and RIS generate large volumes of sensitive data that often sit in unstructured storage with limited auditability.

Erasure is especially challenging. Patient data is replicated across medical devices, lab systems, radiology archives, research environments and cloud backups. On top of that, thousands of clinicians and staff may access the same records, which complicates access governance.

DPDP effectively requires hospitals to retroactively impose order on inherently fragmented systems. That’s why the sector needs intelligence-first platforms that understand medical data contextually, not just structurally.

IT services and GCCs often operate in shared, multi-tenant environments. How does this complexity impact purpose limitation, data segregation and overall compliance?In IT services and GCC ecosystems, the same engineer may work across multiple projects and handle multiple clients’ data within the same environment. This creates a few consistent challenges. Data segregation often becomes blurred, with client datasets sitting in adjacent buckets, virtual machines or shared analytics layers. Purpose enforcement is weak because data collected for testing or migration is frequently reused for validation or automation, often unintentionally.

Data movement is constant. Engineers regularly download, transform and share data across staging, QA, sandbox and offshore environments. DPDP’s requirements around consent, purpose and erasure demand real-time visibility into who is doing what with which data. Without behavioral context and automated guardrails, compliance simply doesn’t scale in these environments.

Many enterprises are turning to generic DPDP tools, assuming they will solve sector-specific challenges. Where do these one-size-fits-all solutions fall short?Most generic tools treat DPDP as a checkbox exercise. They can discover assets, classify files or generate compliance reports, but they don’t understand the meaning of the data, the intent behind access or the purpose behind movement. As a result, they don’t map why the data exists.

They don’t detect abnormal behavioral patterns tied to insider risk or misuse. They can’t enforce real-time controls across SaaS, cloud, endpoints and vendor environments. And they don’t adapt well to sector-specific architectures like core banking systems, EHR stacks, OT environments or multi-tenant GCC setups. DPDP isn’t a documentation problem — it’s a data logic and enforcement problem. One-size-fits-all tools simply can’t bridge that gap.

Shadow data continues to be a hidden risk across industries. Where do you see it typically accumulating, and why does accurate purpose mapping become so crucial in addressing it?Shadow data usually accumulates where control is lowest and speed is highest. That includes analyst exports in BI and ML tools, developer sandboxes and staging environments, backup buckets and logs, collaboration tools like email and shared drives, and vendor pipelines, particularly in analytics or collections. Purpose mapping becomes critical because DPDP is explicit: data must only be used for the purpose for which it was collected. If you don’t know why data exists, you can’t determine whether its presence is lawful, and you can’t enforce deletion, minimization or access controls. Shadow data without purpose mapping becomes a silent liability that often surfaces only during audits or breaches.

How is Matters.AI tailoring its approach to the architectural realities of each industry as enterprises navigate DPDP implementation?Matters.AI operates like an AI Security Engineer that understands the semantic meaning of data, the context in which it’s used and the intent behind access. For BFSI, this means end-to-end lineage tracing across core systems, LOS platforms, partner APIs and analytics environments, combined with real-time DLP for risky workflows. In healthcare, the focus is on semantic understanding of medical data, PHI tagging, clinician behavior modeling and enforcement across HIS, EHR and PACS systems.

For IT services and GCCs, we provide granular monitoring of engineer interactions, client-level data segregation and behavioral risk detection across multi-tenant setups. In manufacturing, we deliver a unified view of employee and vendor data across OT–IT systems, with controls tailored for industrial environments.

Our platform brings together DSPM, insider risk, DDR and real-time DLP into a single layer aligned with DPDP’s core principles: visibility, purpose limitation, governance and enforcement.

Looking ahead, what does the future roadmap for Matters.AI look like, both in terms of product evolution and how you see DPDP-driven modernization shaping the next few years?One major focus is our upcoming AI Assistant for the Data Protection Officer. This will turn DPDP compliance into automated, executable workflows by generating ROPA, DPIA and vendor risk reports, continuously collecting audit evidence, orchestrating DSARs end to end, and providing context-aware recommendations for DPO decisions. The goal is to move compliance from manual effort to proactive, AI-driven governance.

We’re also building full lifecycle control of personal data. Since DPDP centers on purpose, we’re creating automation that governs data from collection to deletion. This includes a unified map of personal data organized by purpose, real-time lineage across systems and vendors, alerts for any use beyond approved purposes, and automated controls for deletion, minimization or anonymization based on consent.

Finally, we’re introducing AI-driven breach simulation. This engine will recreate real-world attack paths across cloud, SaaS, endpoints and internal systems, identify vulnerabilities such as misconfigurations and shadow data, and recommend preventive controls. The idea is to help organizations move from reacting to breaches to predicting and preventing them.

Original source: in