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.