Prabal Pathak on Building Privacy Infrastructure That Scales with Regulation

Prabal Pathak has spent 15 years working at the intersection of data governance and privacy across financial services and technology. He holds the IAPP Fellowship in Privacy (FIP) certification and has led subject rights systems handling billions of data assets. His background spans roles at major financial institutions and technology companies, where he has built the infrastructure enterprises need to respond to privacy regulations while still extracting value from their data.

Pathak discussed with us the technical and organizational challenges behind data subject rights systems, how differential privacy is reshaping analytics, and why privacy programs succeed or fail based on when they enter the product development cycle.

What are the most significant challenges organizations face when building data subject rights systems at enterprise scale, and how can they address them?

The challenge is not the user interface; it’s everything underneath it.

At scale, I see three big challenges:

• First, knowing the data. Most large enterprises don’t have one “system of record or source of truth” for personal data; they have a big volume of apps, data lakes, SaaS tools etc. If you don’t have a reasonably accurate data map or catalog, every subject rights request turns into a scavenger hunt.
  
• Second, reliably linking data back to a person. Identity resolution across channels and systems is another challenge; one person might appear as a customer ID, an email, a device ID, a cookie, or an employee number. If you get that wrong, you either miss data (incomplete response) or over-disclose (privacy breach).
  
• Third, operationalizing legal nuance. The rules are not uniform. What you must do for an access or deletion request in the EU differs from California, which is different again for employees in some jurisdictions or for regulated data like financial records.

What I’ve seen work is:

1. Start with a data governance foundation: Invest in a data catalog, basic lineage and system inventory and establish an enterprise data dictionary so the subject rights engine can orchestrate across systems instead of relying on manual spreadsheets.
   
2. Central orchestration, federated execution. Use a central subject rights service to intake, validate identity, apply policy, and then fan out to connectors in each system of record. That lets you standardize experience and policy while respecting local ownership.
   
3. Codify legal rules into reusable policies. Rather than hard coding “GDPR logic” in every connector, define policy once (who has what rights over what data under which conditions) and let the orchestration layer evaluate that policy per request.
   
4. Treat it as a product, not a one-off project. SLAs, telemetry, continuous improvement, and feedback from legal, privacy and support teams make a huge difference. The volume and complexity of requests grow over time; the system has to keep evolving.

How has the global regulatory landscape, from GDPR to state-level privacy laws, changed the way enterprises approach data governance strategy?

Before GDPR, a lot of data governance was framed around “do we have our warehouse in order for reporting and audits?” Since GDPR (and now CPRA, VCDPA and others), the mindset has shifted in a few important ways.

First, data governance is now a board-level risk topic, not an IT hygiene topic. Boards and executives are asking: what personal data do we hold, why, where, and what’s our exposure if something goes wrong?

Second, regulations pushed enterprises from “collect everything, we might need it” to data minimization and purpose-specific governance. You can’t credibly claim you have a lawful basis and purpose limitation if you don’t even know which business process uses which data.

Third, the regulatory patchwork has forced companies to abstract laws into principles and controls. You can’t build a separate stack for GDPR, another for CPRA, another for Brazil. The smarter organizations build a global baseline (transparency, access, deletion, purpose limitation, security) and then layer local variations in policy, not in architecture.

The other big change is that data governance and AI/analytics are now tightly coupled. It’s not just about records of processing anymore; it’s “which datasets feed my high-risk models, and can I prove they meet regulatory expectations?” That’s where catalogs, lineage and clear ownership have become central to strategy, not nice-to-have.

What role does differential privacy play in enabling organizations to derive value from data while protecting individual privacy, and where do you see its adoption heading?

Differential privacy is one of the few approaches that provides a formal, quantifiable data privacy gate rather than a best-effort notion of “anonymization.” From an architecture and product perspective, it allows us to expose statistics, run analytics, and train models while putting an explicit upper bound on how much any individual’s data can influence the output.

Implementation wise, I think about its role in three patterns:

• Telemetry and analytics on sensitive data capturing product or usage signals (including location or behavioral data, etc.) where we care about trends at the population level but do not want raw event streams to be linkable back to individuals.
  
• Model training and evaluation for high-sensitivity scenarios that help in reducing the risk that an ML model memorizes or leaks user-level data, especially in domains like finance, health, or safety-critical decision-making.
  
• Data sharing and internal federation. One of the critical things is how to enable teams or partners to consume useful aggregates and insights without ever getting direct access to underlying identifiable data.

Based on my experience, I see that the adoption today is still not much. Large platforms and some regulated enterprises have embedded differential privacy into parts of their analytics and ML stack many others are still at the stage of “we know what it is, but it’s not in our reference architecture yet also its still reactive then proactive”

Looking ahead, I expect adoption to grow as:

• Platform-level support: as major data platforms and ML frameworks ship differential privacy as a first-class capability, it becomes a configuration choice rather than a research project (proactive or privacy by design). That’s when it realistically scales across product teams.
  
• External pressure and assurance: regulators and enterprise customers are already asking sharper questions about re-identification risk, especially in the context of powerful foundation models. Differential privacy will not be mandated everywhere, but it will increasingly be recognized as a credible way to demonstrate that you are managing that risk systematically.

In your experience across financial services and technology, what distinguishes organizations that treat privacy as a strategic advantage versus those that view it purely as a compliance obligation?

The way leaders talk about privacy tells you very quickly how seriously the organization takes it.

In the banks and asset managers I’ve worked with, the ones who really get it talk about trust, client experience, and differentiation. Their question is, “How do we use privacy to win and keep clients?” not “What’s the minimum we need to do to pass the audit?”

A few patterns stand out:

• Where privacy shows up in the lifecycle: In mature organizations, privacy is in the room from phase one of the SDLC, when we’re framing the problem and designing data flows, not at the end during UAT. That’s where you decide what to collect, how long to keep it, and which purposes are legitimate. In less mature shops, privacy is still a last-minute approval step, which almost guarantees friction.
  
• How people are measured: When privacy is strategic, product, engineering, and data teams share goals around privacy and data quality. It’s not just a KPI for the privacy function sitting off to the side.
  
• What they choose to build: Leaders invest in reusable capabilities, consent and preference services, subject rights platforms, catalogs and lineage rather than one-off fixes for each new law. You can see privacy embedded in the platform, not just in policy documents.
  
• How they talk externally: Strategic organizations can explain, in plain language, what they collect, why, and where the boundaries are. They’re comfortable having that conversation with clients and regulators and often use it as part of their value proposition.

The result is pretty simple: the first group moves faster with fewer fire drills because privacy and governance are built in. The second group is always reacting to the next law, the next incident, the next questionnaire because privacy was bolted on instead of designed in.

How should privacy and product teams collaborate to ensure that data governance is embedded into product development rather than bolted on as an afterthought?

That’s a great question. I always say: when it comes to privacy, it should be by default and proactive, not something we discover at the end of the cycle.

For me, the biggest shift is when the collaboration starts. If privacy shows up at the end of a release, it’s almost guaranteed they become the team that says “no” or “not yet,” which frustrates everyone. The right pattern is to treat privacy as a core design constraint from day zero, just like performance, reliability, or cost. A few things which work well:

• Start together, not in sequence: Build simple privacy product rituals: privacy input on requirements, early design reviews, and dataflow whiteboarding. That’s where you decide what data you really need and how it should be handled.
  
• Use a standard set of questions: For every new feature: What data are we collecting? For what purpose? How long do we keep it? What are the user’s choices? Which laws and internal policies apply? If the product can answer these early, most downstream friction disappears.
  
• Offer reusable building blocks: Privacy shouldn’t mean every team invents consent flows from scratch. Provide shared services for consent and preferences, subject rights, data classification, and logging, exposed as APIs. Product teams can then focus on experience, not reinventing controls.
  
• Embed privacy into product teams: Align a dedicated privacy PM or counsel with key product areas so there’s an ongoing relationship, not ad-hoc tickets. Over time, product managers begin to anticipate privacy needs themselves.

When you do this, privacy stops being a gate at the end and becomes part of the definition of a “good” product: secure, compliant, and something users feel comfortable trusting with their data.

What metrics or indicators do you use to evaluate the effectiveness of a data governance program beyond basic compliance checkboxes?

I’ll share some leaking KPI’s that help drive the actions:

• Coverage metrics: What percentage of our critical data assets are in the catalog with owners, classifications and basic lineage? If I can’t answer “who owns this dataset and what’s in it?”, governance is not really working.
  
• Subject rights and privacy operations performance: Are we meeting SLAs for access/deletion requests (they may differ for regulations but the key things), and how much of the work is automated versus manual? A lot of manual effort usually signals weak data foundations.
  
• Data quality and incident trends: Are we seeing fewer high-severity issues caused by bad data, and do we detect them earlier? Governance should reduce surprises in production.
  
• Adoption metrics: How often do product, analytics, and AI teams actually use the catalog, policies and patterns we put in place? A beautiful framework that nobody uses isn’t effective.
  
• Speed with safety: Can teams launch new data-driven features faster while staying within risk appetite? If every new initiative gets stuck in months of discovery and approvals, governance is probably too opaque or too manual.

Over time, I’d expect to see actions based on these with better coverage, more automation, and less friction for well-governed use cases.

How can organizations prepare their data infrastructure to adapt to emerging privacy regulations without requiring a complete overhaul each time new laws take effect?

From a product standpoint, the key is to stop “implementing laws” in each application and instead build reusable controls and abstractions that can scale as regulations evolve.

A few principles I would press on:

• Separate policy from implementation: Use a central policy engine and configuration to express who can access what data, for which purposes, under which consent state. When a law changes, you update policy and mappings dozens of microservices and UI flows.
  
• Build common privacy services once: Treat core capabilities like identity resolution for subject requests, consent and preference management, logging, and data classification as shared platform services. New regulations almost always ask for variations of the same pattern if the building blocks are in place, you just compose them differently.
  
• Invest early in foundational data governance pillars: catalog, classify and lineage.
  • Nearly every new law starts with the same questions: “What personal data do you have, where is it, and how is it used?”
     If you’ve already answered that generically through a catalog, lineage, and a basic classification model, adapting to new rules becomes a governance exercise, not an infrastructure fire drill.
    
• Design for minimization and clear purpose from day one: If products collect only what they truly need, with explicit purpose and retention tagging, you have far fewer edge cases to retrofit later when requirements tighten.

In short, the goal is to build a privacy-aware platform with good architecture and shared services rather than 27 slightly different, law-specific solutions that you have to keep chasing and maintaining.

What advice would you give to privacy leaders who are trying to secure executive buy-in for long-term investments in data governance infrastructure?

When I talk to executives about data governance or privacy infrastructure, I always start with business and risk.

Instead of saying “we need a data catalog” or “we need lineage,” I always focus on:

• Here’s our current risk posture: Concretely, regulatory exposure, reputational risk, and operational fragility, backed by real examples or near-misses (e.g., a painful subject rights request, a last-minute AI launch delay, an audit finding).
  
• Here’s how that risk is slowing the business down: Longer onboarding for data partners, slower time-to-market for AI features, and friction in closing deals because we struggle to answer tough privacy and data questions in RFPs.
  
• Here’s a phased product roadmap, not a big bang ask:  1 focuses on a few high-risk journeys and delivers visible wins in 6 -12 months, better subject rights handling, fewer production surprises, more predictable launches, while also laying the foundations (catalog, lineage, policies) we can reuse.
  
• Return on Investment story: Fewer incidents and audit findings, reduced firefighting, faster delivery for data-driven products, stronger win rates where trust and assurance matter. In other words: lower risk and higher velocity.

I also incorporate external signals: what regulators are expecting, how peers are investing, and what large customers are beginning to require contractually. Showing “this is where the market is going, and here’s where we are on that curve” usually creates the right level of urgency.

Finally, I position this as a long-lived capability rather than a one-off compliance project. The message is: we’re building the data and privacy platform on which our AI and digital strategy will depend for the next decade. That framing tends to resonate much more strongly with the C-suite than a narrow “we need to buy a tool to pass the next audit” pitch.