To start with most of the organizations that deal with customer data think that they are doing enough and more to protect their client’s data and have taken all the measures that are needed to safeguard the interests of all the stake holders. They think data privacy compliance is all about putting the documentation in order, to prove that what they are doing is all what is needed.
But most often it’s the other way around. The devil is in the details, and more so if one tries to get into the details systematically.
Let’s use an example to understand this, by taking a case of a fictitious Quick Commerce company.
It has customer base all over the country and delas with multiple vendors. So, they have to mange the data of both clients and vendors.
They believe that they are data privacy compliant because:
- They have published their privacy policy on the website.
- They made their customers agree to their terms of services.
- All their applications run behind a fire wall.
- Al the data transmission happens over secure networks (SSL/https).
- The data at store is encrypted.
Now let us look at what is the ground reality. They perform their data privacy readiness audit and are shocked by what they find.
Data discovery & classification
In my previous blog we talked about classification of data. And going by that definition, the company holds all categories of data – Personal, Sensitive, Children’s and non-sensitive. This challenge exists regardless of whether an organization must comply with GDPR, CCPA, DPDPA, PDPA, or any other data privacy framework. The underlying problem is the same: data is scattered, unaccounted for, and unmanaged.
From the exercise of data discovery, what quickly emerged was that this data was widely dispersed across the organisation. It existed in databases, image repositories, PDF files, email systems, backups, and data exports shared with vendor applications. Ownership of these different data stores was spread across multiple teams, each managing their own systems in isolation.
As a result, no single team had a complete view of where a specific customer’s data resided or how long it was being retained. There were also no clear answers to fundamental questions such as whether the data was protected in line with its classification, whether principles of data minimisation were being followed, or whether the data was being deleted once it was no longer required.
Compounding this challenge was the absence of any mapping between customer data and the applications or locations in which it was stored or processed. Without this visibility, managing data responsibly and demonstrating compliance became increasingly difficult
Consent management
Consent was obtained only once, at the time of onboarding, and treated as just another data point alongside other customer information. It was captured as a broad, generic consent, without clearly articulating the specific purposes for which different types of data were being collected or used.
This falls short of the standards required under virtually every major privacy regulation. GDPR requires consent to be specific, informed, and freely given. CCPA requires organizations to disclose the categories of data collected and the purposes of use. DPDPA similarly requires purpose-linked consent.
Additionally, there was no versioning of consent. Customers who onboarded at different points in time may have agreed to different versions of the terms, but the organisation had no practical way to distinguish which version of the consent applied to which customer, even though terms and privacy notices evolve over time.
Consent withdrawal was also not supported through any automated mechanism. Requests to withdraw consent were handled manually through email exchanges, making the process slow, operationally intensive, and difficult to track consistently.
Children’s data handling
In the case of minors who were onboarded onto the platform, age verification was not part of the registration journey. As a result, the organisation had limited visibility into whether the user was a minor at the time of onboarding.
Even in instances where users indicated that they were underage, there was no structured process to seek and record verifiable consent from parents or legal guardians.
This is not a niche requirement. GDPR Article 8 requires parental consent for children under 16 (or a lower age set by member states). The US Children’s Online Privacy Protection Act (COPPA) mandates verifiable parental consent for children under 13.
India’s DPDPA similarly requires organizations to obtain verifiable consent from parents or guardians before processing children’s data.
The specific age thresholds differ by jurisdiction, but the obligation is consistent: organizations must know when they are dealing with minors and must have a compliant process to handle that data.
Individual’s rights
When a data principal (the customer, in this case) requested deletion of their data, the request was managed through email exchanges and typically took three to four weeks to complete. No audit trail was maintained for these requests.
There was no system-level enforcement to ensure that the data was deleted across all systems where it resided.
A similar challenge arose when customers requested information on what personal or sensitive data was being processed and for what purposes. There was no centralized mechanism to provide this information, requiring coordination with multiple application owners and external vendors. This process was time-consuming, operationally inefficient, and placed significant strain on internal teams.
Note: the right to erasure, the right to access, and the right to data portability are recognized under GDPR (where individuals are called “data subjects”), CCPA (where they are called “consumers”), DPDPA (where they are called “data principals”), and other frameworks. The label differs but the obligation does not.
Vendor management
There were no mechanisms in place to conduct periodic vendor compliance assessments. Identity documents collected for KYC and onboarding purposes were retained indefinitely, with no provision for deletion even after the vendor relationship was terminated.
In addition, analytics data shared with external partners contained raw personal identifiers.
Under GDPR, this constitutes a failure of controller-to-processor obligations. Under CCPA, sharing personal information with third parties without appropriate disclosures or agreements creates significant risk. Under DPDPA, data fiduciaries are required to ensure their data processors handle personal data responsibly and only for specified purposes. Across all frameworks, the principle is consistent: vendor relationships do not dilute your accountability for the data you collect.
Incident management
To assess the effectiveness of their incident management workflow, the organisation tested a common scenario in which a customer requested the deletion of all personal data.
While the application team removed the customer’s profile, the customer’s data continued to exist in the CRM system, and related call centre recordings were still retained. Additionally, the third-party KYC vendor continued to store the customer’s Aadhaar details.
This exercise revealed that data deletion was being handled as a series of isolated actions rather than as a coordinated, end-to-end process.
Conclusion
This organization was not negligent. It had invested in security, policies, and infrastructure. Yet, it fell short because data privacy compliance is not about intent or documentation, but it is about operational reality.
And this is true whether the applicable regulation is GDPR in Europe, CCPA in California, PDPA in Singapore or Thailand, PIPEDA in Canada, or DPDPA in India.
Major organizations globally have learned this lesson the hard way. British Airways was fined £20 million under GDPR for a breach exposing data of over 400,000 customers. Meta received a €1.2 billion GDPR fine for unlawful data transfers. T-Mobile paid $350 million to settle a class action following a breach affecting 76 million customers. In India, organizations like Star Health Insurance and Policy bazaar have experienced large-scale data exposures, where millions of customer records were leaked due to security and privacy gaps.
These incidents reflect weaknesses that go beyond infrastructure, such as lack of data mapping, incomplete consent or retention practices, and inadequate breach response, all of which modern privacy regulations are designed to address.
The pattern is global: organizations that treat compliance as a documentation exercise rather than an operational discipline will eventually find themselves on the wrong side of a regulatory investigation or a data breach.
Organizations must now take a hard look at how customer data is managed and put in place the governance, systems, and processes required to meet their data privacy obligations, wherever in the world they operate.
