Data Breach
India’s new draft data protection law mandates that data fiduciaries must notify affected individuals and the Data Protection Board of a breach, but it lacks specifics as to timelines or remedial actions. I worry that over-reporting minor incidents could lead to public desensitization, and would have preferred a more balanced approach that only requires notification of only the most high-risk breaches, similar to the European GDPR.
This article was first published in The Mint. You can read the original at this link.
Despite the many ways in which our privacy can be violated, we are, arguably, at our most vulnerable when the data we’ve entrusted to a service provider somehow makes it into the public domain. Small wonder that one of the questions I am almost always asked when I talk about our latest data protection law is whether and to what extent it protects us against a personal data breach.
Securing Your Data
Before I get into what the draft law does (or does not do), I want to first disabuse you of the notion that you are helpless to protect yourself in such circumstances. The most serious fallout of a data breach is that your credentials (the username and passwords that you use to log into digital services like online banking and social media) could fall into the hands of the criminally inclined — who could then siphon money out of your accounts or trash your online reputation. Since most of us settle on a single (hopefully) strong password that we then use across a variety of services, a single data breach puts at risk not only the service from which the breach occurred, but every other service in which the same password was re-used.
While it is virtually impossible for anyone to remember a different random password for every service they use, modern password managers offer a simple solution to this problem by storing multiple login credentials in a vault protected by a single powerful password. Committing to use a password manager can greatly reduce the cascading consequences of a data breach incident. If, in addition, two-factor authentication is turned on, even if your username and password get compromised, no one can access your account without first gaining control of your phone or the authenticator app that generates a one-time passcode needed to unlock it. Simply implementing these two workflows can offer more effective protection against a breach of your personal data than any law could ever hope to achieve.
That said, data breaches do occur and we need to stipulate what data fiduciaries need to do to if the data entrusted to their care somehow manages to get into the hands of criminal elements.
Breach Notification
India’s new draft data protection law makes simplicity a priority. This philosophy has been extended to its provisions on breach notification as well. Included among the many general duties of data fiduciaries that have been laid out in Section 9 is a short section on their obligations in the event of a data breach. Data fiduciaries are required to not only notify the Data Protection Board, but also each affected data principal of the occurrence of a breach. Unlike previous drafts, and indeed most data protection legislation around the world, it makes no mention of how soon such notification should be made or any other remedial action that ought to be taken.
As those who follow my work would have gathered by now, I actually like the simplicity of India’s current approach. I believe that this is exactly what we need at this stage of our data protection journey, and so have no quarrel with the lack of specificity in the law or the fact that the form and manner of notification has been left to be prescribed later. While these are the issues most critics have complained about, the one feature that they have commended—the draft bill’s requirement to notify every affected data principal of the data breach—is actually what concerns me the most.
Notifying Data Principals
Not every data breach puts your data at risk. Given how broadly the term has been defined, any incident that even momentarily results in the data fiduciary losing access to data entrusted to their care becomes reportable. A laptop containing customer information accidentally left in a taxi and a server that goes offline temporarily for reasons that cannot be immediately ascertained are examples of incidents that fall within the definition of a “data breach”. So these are events that every affected data principal would need to be informed of, even if it is impossible to tell for sure whether their data was actually accessed by someone not authorised to do so.
While it might seem appropriate that we make each data principals aware of all possible data-breach incidents that could even remotely affect them, over-reporting will cause unnecessary panic. Without additional knowledge, we tend to assume the worst, which will result in more consternation than is necessary. And then, after the first few reports, when customers realise that not all breach incidents are actually dangerous, they will start paying them less and less heed. To the point that when they inevitably have to deal with a really serious data breach, they will take it more lightly than they should.
Balance
Our approach should be to require data fiduciaries to report only those incidents that are likely to result in high risk to the rights and freedoms of natural persons. This is the approach that most modern data protection laws, such as the European General Data Protection Regulation, adopt—with good reason. As much as we might feel that knowledge of an incident, no matter how innocuous, gives individuals the power to determine for themselves what they should do to protect themselves, given the frequency at which these events occur and the wide range of their severity, bombarding the populace with breach notifications will not be effective.
As we finalise our data protection law, it is these small nuances that need attention. We need to understand how these obligations play out in the real world. And we should ensure that we don’t sacrifice practicality at the altar of simplicity.
