Most conversations around data protection begin with legal readiness.
Has the privacy policy been updated? Has the notice been drafted? Has the organisation identified its obligations?
Those questions matter. But there is another question that may ultimately be more difficult:
Can your technology systems actually execute what your privacy framework promises?
Because there is a large difference between having a privacy policy and having privacy-ready infrastructure.
Consider something as simple as withdrawing consent
Imagine a customer gave permission to use their email address and phone number for a particular purpose. Months later, the customer withdraws that consent.
From the user's perspective, the request is simple. From the organisation's perspective, it may not be.
The phone number may exist in a CRM, a marketing platform, an ERP, an analytics database, a mobile application, a customer-support platform, a data warehouse and one or more third-party systems.
Now the organisation must determine: Where is the data being processed? Which processing activities depended on that consent? Which activities can continue for another lawful reason? Which systems need to receive the change? Can the organisation prove that the withdrawal was actioned?
Suddenly, a simple privacy request becomes a system-integration problem.
Privacy obligations eventually become system requirements
The DPDP framework establishes requirements around lawful processing, notice, consent, security safeguards and rights available to individuals. The notified Rules further require notices to clearly describe the personal data involved and the specified purpose or purposes for processing.
Those requirements may appear legal when written on paper. But implementation translates them into technology questions.
Notice becomes a user-interface and content-management question. Consent becomes a permission-management question. Purpose limitation becomes a data-governance question.
Withdrawal becomes a workflow and integration question. Retention becomes a data-lifecycle question. Accountability becomes an audit-trail question.
This is why privacy cannot be implemented by the legal team alone. It requires legal, technology, security, product and operational teams to work on the same data model.
Most enterprise systems were not built for this
CRMs were designed to manage customer relationships. ERPs were designed to manage operations. Marketing platforms were designed to run campaigns. Analytics tools were designed to produce insights. HR systems were designed to manage employees.
Each application is highly capable within its own purpose. But historically, few enterprise systems were designed to answer privacy questions such as: Why was this particular piece of personal data collected? What purpose is currently associated with it? Which notice was shown when it was collected? What permission governs its use? Has that permission subsequently changed? Which downstream applications received the data?
That missing context creates what can be called a privacy metadata gap.
The organisation possesses the data. But it may not possess enough information about the conditions governing that data.
Your systems may know the customer, but not the permission
A CRM may know that Customer A has a phone number and email address. Privacy operations require additional context: when it was collected, the purpose, the notice version, the consent status, any separate marketing permission and the systems or processors with which it was shared.
That second layer of information is becoming increasingly important. It creates a relationship between data and permission.
Without it, privacy teams are forced to reconstruct the history of personal data after an issue appears. At scale, that approach is neither efficient nor reliable.
A useful readiness test
Instead of asking whether your organisation has completed its compliance documents, ask whether it can answer five questions for a piece of personal data:
- What is it? Can we identify and classify the information?
- Why do we have it? Can we associate the data with a defined purpose?
- What allows us to process it? Can we identify the relevant permission, consent or other applicable basis?
- Where is it being used? Can we trace the systems, processes and third parties interacting with it? 5. What happens when something changes? Can a withdrawal, correction, deletion or policy change propagate through the relevant systems?
If answering these questions requires weeks of emails, spreadsheets and manual investigation, the organisation may have a privacy programme. But it does not yet have privacy-ready infrastructure.
Privacy has to become connected
Privacy platforms cannot remain disconnected repositories where policies and consent records are stored independently of the systems processing the actual data.
The next generation of privacy infrastructure will need to communicate with the enterprise technology stack: CRM, ERP, applications, websites, HR platforms, data repositories, APIs and cloud environments.
The goal is not to replace these systems. It is to give the organisation a governance layer that understands how personal data moves between them and what rules should travel with it.
This is an important part of the thinking behind iConsent.
Compliance is the starting point, not the architecture
Legislation creates the obligation. Technology determines whether that obligation can operate at scale.
As India's privacy framework matures, organisations will increasingly discover that the difficult part is not writing what should happen. The difficult part is ensuring that hundreds of systems, workflows and people consistently make it happen.
So perhaps the most useful readiness question is no longer: Are we compliant? It is: If an individual changes how their data may be used tomorrow, will our systems know what to do?
The answer to that question reveals far more about an organisation's privacy maturity.
