Busting 10 data protection misconceptions about the DPDPA

Securys has been delivering modern data protection compliance for more than a decade. In that time, we’ve built programmes for organisations of all sizes, in every sector and across 70 countries. Every customer is different but common themes emerge; in this, our latest article we set out to highlight some of the most persistent misconceptions about data protection. Our particular focus here is on compliance with India’s new Digital Personal Data Protection Act, but many of the lessons are globally applicable.

Misconception 1: data protection is all about breach prevention
Breaches matter – they carry risks of regulatory penalty, litigation and loss of customer trust. Effective cyber security is indeed one of the key requirements in data protection, but neither the only requirement nor necessarily the most important. The easiest way to explain the difference is that cyber security asks the question “can I do this processing safely?” while data protection asks the question “should I be doing this processing at all?”. It’s entirely possible to be fined (or sued) for failure to comply despite perfect success in keeping personal data confidential.

Data protection has seven key principles:

1. Transparency: data principals must know what you are doing with their data, in what fashion, why you are doing it, with whom you are sharing it and what rights they have with respect to it.

2. Lawfulness: all processing must have a justifying legal basis; in India this is mostly consent, but very much not only consent. More on this later.

3. Accuracy: personal data must be accurate – that is, must properly reflect reality – and should be sufficient properly to inform your decision-making.

4. Limitation of purpose: you should only collect and process personal data for the specific purposes for which you have identified a justification and which you have declared to the data principal.

5. Minimisation: the personal data that you collect should be strictly limited to what is necessary for your identified purposes and should be retained no longer than is necessary to fulfil them.

6. Security: personal data should be collected, processed and stored with continuous attention to the maintenance of confidentiality, integrity and availability and the limitation of access to those persons with a clear need in support of the identified purposes of processing.

7. Accountability: you, as the data fiduciary, are accountable to the regulator and to the data principal for all collection, processing and storage of personal data that is undertaken on your instruction, whether by you or other parties. You must have demonstrable internal reporting and verification mechanisms to manage this accountability, including a clear line of reporting to the top of your organisation.

Your data protection programme needs to ensure that every act of collection, processing and storage of personal data is scrutinised through the lens of all seven of these principles, and that you can evidence that scrutiny and the actions you have taken as a consequence. You must demonstrate that you appropriately assess the risks to the data principal of your processing and take necessary steps to treat those risks, that you monitor and control processing of personal data that you share with third parties and that you consider and manage the risks of transfer of personal data to other countries.

Misconception 2: data protection compliance is just paperwork
Being able to demonstrate compliance by producing documentation is a significant part of data protection compliance. This documentation includes public and employee-facing privacy notices for transparency; internal policies and procedures to ensure proper controls; records of processing to identify each purpose and its justification; evidence of consent, including histories of grant and withdrawal; detailed risk assessments and the treatments they engender; contracts and agreements for the sharing of data with third parties and for processing of data under your instruction; records of those transfers of data; logs of breaches and near misses; and internal and external reports on compliance, including in some cases formal data protection audits. All in all, there is indeed a lot of paperwork.

However, the substance of data protection is not that paperwork, it’s the organisational transformation that is required to ensure that you actually do what your records say you are doing. Every internal process needs to be reviewed to ensure that personal data is being processed in accordance with your policies, and the process needs to change if it is not compliant. All of the risk treatments you identify in your assessments need to be implemented and verified. All of your third-party data sharing partners need to be managed and their performance closely monitored. All of your systems need to be reviewed and where necessary changed in order that you can properly comply with the law and with requests from data principals for correction, completion or erasure of, or access to, their data; challenges to decision-making; and withdrawals of consent. Everyone in your organisation who has access to personal data must receive privacy awareness training that is sufficient for their degree of involvement in processing and decision-making about processing.

This is a whole-organisation transformation programme that requires both top-down policy making and bottom-up process review and change; it needs the whole-hearted sponsorship of senior management and the resolute involvement of process owners at every level.

Misconception 3: it’s all about consent
The DPDPA is very much a consent-first law, but this comes with several challenges. First of all, there are other reasons for collecting, processing, storing and – crucially – sharing personal data, including for the purposes of employment; meeting legal requirements imposed by the state; and complying with legal judgements. There are provisions for public health and the saving of life, and processing by the State and its instrumentalities is legitimised without the need for consent but within a strict framework.

More importantly, consent is not as simple as you might think. Consent under DPDPA is granular – that is to say, specific to each individual act of collection and processing – and must be fully informed, freely given, separated from any contract and as easy to withdraw as it is to provide. “By ticking this box you consent to our processing of your personal data” is not good enough.

The crucial question, though, is what you do when consent is withdrawn. Consider a simple example: a customer opens a bank account. In doing so, they provide consent for a number of different purposes of processing from initial due diligence and anti-money-laundering to day-to-day transactional banking through use of their data for internal process improvement and finally consent to receive marketing materials. Each of those consents can separately be withdrawn, and each will have different consequences for which your systems and processes must provide. You will need to think about how you deal with each possible combination of valid and withdrawn consents, and how you inform the data principal of the consequences of any withdrawal. The law provides some examples of how you may continue service of a contract after consent has been withdrawn, but this is open to challenge and will be interpreted strictly. In the context of this bank account example, ask yourself: “if the customer withdraws consent for day-to-day processing, on what basis am I allowed even to look up their balance so I can return their money? And do I want to allow them to close their account just by withdrawing consent?” Ask yourself “If they withdraw consent for the use of their data for process improvement, how do I ensure that their data is not included in our analytics when we look at account usage patterns?” There are answers to these questions; the point we are making here is that you need to consider them, and that therefore consent is by no means as simple as one tickbox and you’re done.

Misconception 4: personal data means PII
The world has inherited from the Americans the term “Personally Identifiable Information” or PII, which is commonly used to refer to a limited set of details such as PANs, driving licence numbers, passport or Aadhar numbers and so forth. While that information is certainly all personal data, the definition in the DPDPA is much wider – the term refers to any information about a natural person held in a context in which they can be identified. Everything you digitally record about someone is personal data including photos, audio and video.

Misconception 5: consumers don’t care about privacy
“Privacy is dead” “Consumers only want convenience” “Consumers only want the lowest price” – all of these statements are used to justify minimising efforts to deliver compliant data protection programmes. We didn’t agree, so we did the research. Visit privacymadepositive.com for access to the full reports on our multiple survey programmes; the headline is that 70% of consumers include privacy in their decision-making. This applies both to aversion – a decision not to proceed because of concerns about their data – and selection – choosing one product or service over another on the basis of better data protection.

Misconception 7: no consumer customers, no problem
All people are data principals. So even if you’re a manufacturer or a B2B service provider, you will still have data protection obligations to your employees, your former employees and pensioners, every past and present employment candidate, your counterparties at your suppliers and customers, any visitors whose data you collect and anyone from the wider community with whom you have digital contact. While you don’t have to deal with quite as much of the consent issue because employment processing is a justification in itself for processing, all of the same principles around transparency and data principal rights still apply to you, and you are still accountable as a data fiduciary.

Misconception 7: regulators are only interested in big tech companies
Elsewhere in the world, it’s the hundreds of millions (or even billions) in fines levied against the big US tech companies that get headlines in the mainstream press. In reality, though, data protection enforcement is continuous and applies at all levels. At the time of writing there have been 335 publicly notified fines in Europe in 2025, as well as many more interventions that required process change or improvement without an immediate monetary penalty; of those 335, only 3 were directed at one of the big tech firms. The total fines levied were €1.1bn (about ₹11,360 Cr, an average of ₹34Cr per fine).

Misconception 8: it’s an IT problem, and a GRC system will solve it
Because it’s seen as a problem, not an opportunity, and because it’s perceived to be an IT problem since it revolves around data processing, privacy compliance is often handed to the IT team to handle. In turn, the IT team often looks for a software solution. There is no shortage of software in the data protection space – from discovery tools, encryption systems and redaction products through cookie and consent management platforms to so-called “Governance, Risk and Compliance Systems”. All of these do indeed have their role to play in achieving DPDPA compliance, but none of them will do it for you.

Data discovery tools help you find personal data, but they don’t decide whether you should be processing it or – in most cases – even give you an understanding of why you have it in the first place. Encryption systems can, when properly deployed, protect confidentiality but they don’t make your processing lawful and can’t decide for you what to encrypt in the first place. Redaction tools are essential in complying with data principal access requests, but you still need to decide what information to withhold on a case by case basis. Cookie managers let you collect consent for cookies – once you tell them what cookies you’re using – but they don’t choose for you, and they don’t manage your accountability for processing by all of the partners with whom that cookie data is shared. And consent management platforms will be a vital part of DPDPA compliance, but all they can do is permit the granting and withdrawal of consent; they won’t by themselves make your processing respond appropriately to those actions by data principals, or develop the right consent wording, or decide whether consent is the right basis for processing in the first place.

In particular, GRC systems are just structured databases in which to store and manage the compliance paperwork we discussed earlier. They need careful implementation to match your business, they need to be populated with your data assets, processes, systems and third parties, and while they’ll help you record your risk assessments and controls, they won’t actually perform those assessments, identify those controls or implement them for you. A good GRC system is an essential component of an effective compliance programme, but it doesn’t substitute for whole-organisation effort in process transformation, and it won’t remove the need for specialists to assess and achieve compliance with the eight principles.

Misconception 9: the DPO will deal with it (and it’s a part-time job)
The role of the Data Protection Officer is commonly misunderstood. In India, a DPO is only required for a Significant Data Fiduciary (SDF) but may be appointed by any fiduciary; their role is to act as the fiduciary’s representative and the point of contact for data principals seeking redress for a grievance and they are required to report to the Board of Directors or a similar level of governance. They are not the person, or function, that is responsible for operational decisions about processing and data protection, for preparing and maintaining compliance documentation and systems or for supporting your team with training and answers to questions.

For an organisation of any significant scale, that privacy operations role – what we call the Privacy Office – is a material undertaking involving a team of people with the right training, systems and support, backed by senior management sponsorship and a network of privacy champions laced throughout the business. Their job is to help you find the right balance that allows your organisation to succeed in a data-driven world while remaining compliant with the rules of Data Protection; this is an ongoing and evolutionary process requiring a combination of skills and informed judgement.

The DPO, on the other hand, in addition to the liaison with data principals, is your point of contact with the regulator and functions to hold you to account for compliance; they are an auditor and verifier, not a decider and doer. In Europe, the DPO is often described as “the embodiment of the regulator within the entity” and you must be able to demonstrate their independence and autonomy. Notably in India, SDFs will also be required to commission an independent auditor who will annually verify compliance and compile a Data Protection Impact Assessment. The interaction between the DPO and the auditor, along with the precise identification of SDFs has yet to be clarified in the rules that have been published to date.

Misconception 10: delegating processing delegates compliance
This is a simple one: the principle of accountability means that you – the fiduciary – are held responsible for any collection, processing and storage conducted on your instructions by any party. It is your duty to ensure that your third-party providers work in compliance with the DPDPA and only carry out the processing you have instructed. Your only defence if a processor breaks the law is to demonstrate that you had carried out all reasonable due diligence, concluded the right contractual provisions and carried out sufficient regular compliance checks.

Even where you are sharing data with another fiduciary, the responsibility is shared, not transferred. You still have to demonstrate that the transfer is necessary and appropriate; and that you have an agreement providing necessary controls and collaboration to assure data protection.
Whether you are transferring data to a processor or to another fiduciary, it becomes more challenging still if the other party – or their data storage or processing – is outside the country. While we’re still waiting for the detailed rules on international transfers, we know that elsewhere in the world this requires specific risk assessment, additional contractual provisions and brings greater exposure to regulatory scrutiny.
All of this makes third-party risk management a crucial part of an effective DPDPA programme; it’s important in this context to be cognisant of the sheer number of third parties with whom a typical organisation shares data – in our experience a typical Tier 2 financial institution will have more than 1,000 sharing partners, each of whom needs an individual risk assessment, contract review and risk treatment plan.

Why now is the time for action
So far what you’ll mostly have taken from this article is that DPDPA compliance is more complicated, more onerous and – inevitably – more expensive than you had thought. All that is true. But, and it’s a big but, an effective compliance programme is also a huge opportunity.

Why?
Firstly, because in order to become compliant you need to map every piece of personal data in your organisation and understand how it is used, by whom and for what, with whom it is shared, how long you keep it and why you think that processing is worth doing in the first place. You could, like many before you, keep that information in a compliance silo. Or you might consider the value of that kind of mapping in identifying process inefficiencies and duplication, revealing flaws in decision-making processes and understanding supply chain risks. To say nothing of the reduction in cyber attack surface that comes from reducing both the volume of data you hold and the number of people with access to it. That transformation programme we described earlier doesn’t just result in a compliant business; it results in a leaner, more efficient and more profitable one also.

Secondly, you’ll recall our Privacy Made Positive® research. That showed the extent to which good privacy practice – if you publicise it properly and show that you genuinely care about data principals and their outcomes – can be a competitive advantage. In competitive and commoditised markets where differentiation hangs on reputation and customer perception, compliance is a surprisingly effective lever in improving trust scores and driving better retention and conversion.
Finally, and most importantly, because it will change how you think about data and what you can get from it. The danger of compliance programmes is that they lead you to think of data as a risk – and certainly, if you don’t deliver effective data protection, a risk is what it will be. But the reality is that data should be an asset, one that you protect because it has value and delivers a worthwhile return. If your data is current, deduplicated, accurate, properly linked to a single customer view, securely stored and processed and properly consented by data principals who trust you, it transforms into your most valuable asset and the key to data-driven growth.

If you’d like us to help you achieve DPDPA compliance and transform your data from a risk into an asset, you can Contact Us.