DPDPA: When Compliance Moves From the Policy Folder to the Real World

The next challenge isn't understanding privacy. It's making privacy part of how the business works.

In my first blog, I wrote about why DPDPA is not just another compliance law. The November 2025 notification changed the conversation and organizations started asking a much more practical question: Are we actually ready?

But after asking that question, another one follows:

What does being ready actually look like?

It is easy to say that an organization has a privacy policy, an access control policy, a retention policy or  a vendor management framework.

It is much harder to prove that those policies are reflected in everyday work.

From my experience across Business Operations, Procurement, Vendor Governance, IT Asset Management and GRC, this is where I see the real challenge.

Compliance is rarely difficult to write down. The difficult part is making it happen consistently.

And DPDPA will bring that difference between policy and practice into focus.

The Policy Says One Thing. What Does the Process Do?

Take employee onboarding.

The policy may clearly state that system access should be approved before it is granted.

But what happens when a new employee joins on Monday morning and needs access immediately?

Does the process automatically trigger the required approvals? Or does someone send an email, follow up on a call and eventually grant access because the business needs the employee to start working?

Now take employee exits.

The policy may require access to be revoked when an employee leaves. But is HR notification automatically connected to IT? What happens to application access, shared folders, email accounts and physical assets? Who confirms that everything has been completed?

The same applies to asset allocation, vendor onboarding, visitor management, record retention and data deletion.

The organization may have a policy for all of them.

But a policy describes the expected behaviour. A process determines the actual behaviour.

That is why I believe DPDPA implementation will expose process gaps that organizations may have been living with for years.

The Data Problem Starts With a Simple Question

Before an organization can protect personal data, it needs to understand where that data actually exists.

This sounds simple until you start mapping it.

Customer information may be in the CRM.

Employee records may be in the HRMS.

Vendor information may sit in an ERP or procurement platform.

Finance may have invoices, bank details, tax documents and payment records.

Recruitment teams may have thousands of resumes.

Marketing may maintain campaign lists.

Operations may rely on spreadsheets and shared folders.

Then there are emails, Google Drive, Microsoft 365, laptops, cloud applications, backups and messaging platforms.

And sometimes, there are copies of the same data sitting in places nobody remembers.

Now ask yourself:

Can your organization confidently answer where its personal data is stored, who can access it, why it is being retained and what happens when it is no longer required?

If the answer is not a confident "yes," there is work to do.

Data mapping is not just an IT exercise. Business teams need to explain how data enters their processes, where it moves, who uses it and when it should leave.

You cannot govern what you cannot see.

Privacy Has No Departmental Boundaries

This is also why I don't agree with treating DPDPA as an Information Security project.

Information Security will have an important role. Legal will have an important role. But neither team can see every interaction with personal data.

HR manages employee and candidate information.

Finance handles banking, payroll and statutory records.

Sales collects customer and prospect information.

Marketing manages customer preferences and campaign data.

Procurement handles vendor information and third-party documentation.

Operations connect many of these activities through daily workflows.

Legal manages contractual and regulatory requirements.

IT manages systems and access.

Information Security protects those systems and manages security risks.

Everyone sees a different part of the data lifecycle.

That means one team can coordinate the privacy framework, but every team has a role in making it work.

For me, this is one of the most important mindset changes DPDPA can bring to organizations.

Privacy may have an owner. Accountability cannot.

The Biggest Risk May Be the Shortcut Someone Takes to Get Work Done

When privacy and security are discussed, technology usually gets most of the attention.

DLP. IAM. Encryption. Monitoring. Access controls. Security platforms.

All of these have their place.

But there is another layer that is much harder to control: human behaviour.

An employee sends a personal-data-filled Excel file to a personal email account because they need to work from home.

Someone downloads a report onto a laptop and forgets about it.

Someone gives an entire team access to a folder when only two people actually need it.

Someone keeps an old database because "we might need it later."

Someone shares personal information over WhatsApp because it is faster.

These actions are not always malicious. Most of the time, people are simply trying to get their work done.

That is why privacy awareness cannot be limited to an annual training session or a policy acknowledgement.

Employees need to understand the practical side of privacy: what they can share, where they can store it, who should have access, how long information should be retained and what to do when they are unsure.

Privacy is a culture problem before it becomes a technology problem.

This Is Where Business Operations Comes In

This is the part of DPDPA implementation that I find particularly interesting.

Business Operations often sits between people, processes, vendors, technology, documentation and governance. That makes it a natural bridge between a policy requirement and actual execution.

Take onboarding.

Instead of treating access approval as a separate IT activity, it can be built directly into the employee onboarding workflow.

Take employee exits.

HR notification, access revocation, asset recovery and data handling can be connected into one defined process rather than relying on multiple teams to remember their individual responsibilities.

Take retention.

A retention schedule is useful, but it becomes much more valuable when the underlying process actually triggers review and deletion.

Take vendor onboarding.

Privacy and security requirements can be evaluated before the vendor starts processing information instead of becoming a discussion after the contract is already signed. I will go deeper into this in the third blog of this series.

This is where compliance starts creating operational value.

Good privacy practices can also create better business processes.

The Real Readiness Test

So, how do you know whether an organization is genuinely ready?

Don't start with the policy folder.

Start with the workflow.

Pick an employee onboarding process.

Pick an employee exit process.

Pick a vendor onboarding process.

Pick a data retention process.

Then ask:

Where does personal data enter? Who touches it? Who approves access? Where is it stored? Who is accountable? And what happens when the purpose is over?

The answers will tell you much more about privacy maturity than the number of policies you have.

The first blog in this series was about why businesses need to take DPDPA seriously.

This blog is about what happens after they do.

Because DPDPA readiness is not created by another checklist, another software purchase or another policy sitting in a shared folder.

It is created when privacy becomes part of the way the organization works.

And ultimately, DPDPA will not be tested by what an organization says it does.

It will be tested by what it actually does.

That's where privacy stops being a compliance requirement and becomes an operational discipline.