This Article is written by Vansh Ved from the Institute of Law, Nirma University and the article has been edited by Khushi Sharma (Trainee Associate, Blog iPleaders) and Vanshika Kapoor (Senior Managing Editor, Blog iPleaders).

Introduction 

Data, the most fluid substance in the internet world, has a tendency of always being at risk at every single point of storage, collection, transfer or any other operation performed on it. Breaches, hacks, unauthorized break-ins into systems, viruses, are some of the most common dangers data faces while being processed anywhere anytime. 

Incident management, simply put, is the process of identifying, handling, documenting and remedying an attack or danger on data and overall, finding a solution to an ‘incident’ that has occurred on a piece of data. The purpose of such a system of management is what defines the scope of it, being primarily, protecting users or any other data and securing an organization’s server or technology systems.  

An incident management system or team is formed according to the guidelines and regulations set out by respective applicable laws as well as necessary technical requirements and practices, all of which in resonance, is meant to ensure security, protection and solutions in the event of a threat to the data.  

To further study the technological as well as regulatory/legal practices and requirements an incident management system is built from, we would have to have a fundamental look at the basics of the same.  

Ingredients of data breach incident management system

A data breach incident management system or project, meant to secure and protect data and retain its privacy in the event of attacks or breaches, typically consists of some basic elements:

Detection

• The moment of identification, detection and further acknowledgement that an incident has occurred on a piece of data stored by an organization or a data fiduciary (a data controller or processor) is the moment of detection of an attack or a Breach. 
• A breach as a form of an attack can take several forms and intensities and each such form can have a different plan of action for correcting it. The tools, duration, documentation, communication and regulation for remedying such breach can vary largely, based on several other factors such as the magnitude of the breach, the sensitivity or criticality of such data, or even the technological systems available and in place with the host of such data. 
• The Discovery of a breach can either be reported or self-discovered by the processing organization. It is either reported by the data principles/subjects (to which the data relates to, in case of personal data) that may find out about such breach through a third-party having unauthorized access to their personal data that the subject provided to the processing organization or through a further incident with the data subject that might have involved a loss of information or privacy. This is the same for third-party users and customers. Apart from this, a breach can be observed by the fiduciary themselves either through its employees or through an alert in the system regarding a data breach or attack from a virus or a hack that is potent enough to cause a breach. 
• The information about such breach, however discovered is then meant to reach the management of an organization as well as it’s IT team in order to start responding to the current as well as potential attacks as soon as and as effectively as possible. 

Response

• Incident Response is a commonly known procedure in the cybersecurity space for remedying the aftermath of an attack or a breach on a company’s servers or its data. 
• There are essentially two ways an incident management team responds to a breach – one of them being at the very moment of gaining knowledge of such a breach, known as the Initial Response, and the other being the well-thought, remedial and more textbook response that is performed as a full and final solution to the attack, known as the Continuing Response. 
• The Initial Response is aimed at containing the escalation of a breach to as much extent as possible. The immediate steps in the direction of securing the server or data that has been breached can prove to be extremely crucial in saving the damage caused by the incident. The initial response process also includes proper analysis of the problems and designing a plan to solve them. 
• Continuous; more investigation, regulatory, case closure. The Continuing Response is aimed at finding and executing a final solution to the breach. It involves thorough investigation and analysis, followed by a full-fledged plan of action that is compliant with all the regulatory requirements and applicable laws or guidelines as well as has a required technological security system and practice ready for acting and protecting the data or even tracking down the invader. 

Documentation

• As a requirement under almost all the regulations around the world, as well as a recommended cybersecurity practice, documenting investigations, risks, measures to mitigate those risks, compliance documents as well as licenses and agreements. 
• Documentation is not just important for external communication but also for legal requirements in case of future needs and even a company’s internal communications in the form of analysis and personal records.

Communications

• Notification after documentation is considered an extremely important step under almost all the regulations around the world. Such notification refers to the communications of such incident/s to the data subject as well as the authorities. Communications to authorities typically have a mandate of being delivered within a limited period of time, whereas notifications to data subjects generally have the mandate to be done based on the type of data or the risks related to the breach. 
• Communications regarding a major breach relating to personal data are usually taken to the press tagged along with the extent of damage, number of subjects whose data is compromised and actions that the organization plans to take to mitigate the risks. 

Tech tools

• To explore the latest technologies and tools to prevent or once occurred, mitigate risks of data breaches in an organization of any size, there are several software and hardware systems that help give a one-stop-shop solution that includes firewalls, antiviruses, encryption systems, password protectors and tens of other tools that can ensure as much security as is technologically possible.

What does the GDPR states

Notification and Documentation are the two parts of incident management that the General Data Protection Regulation of the European Union, strictly regulates and mandates organizations to follow. To state simply, incident response is the biggest task of the Act. 

Article 30 of the Regulation talks about the Records of processing activities. It mentions the elements of processing required to be necessarily documented and the conditions under which they can be asked to make available. The purpose of this article is to confirm compliance in the case of a data breach. Additionally, also for a supervisory authority to help give out instructions or guidelines in the event of a breach.

Article 33 of the GDPR sets out the guidelines for the notification of a breach to the supervisory data protection authority. The article sets out a time limit of 72 hours for notifying the authority of such breach unless there are legitimate reasons submitted for a delay. In cases of a processor being responsible for the data in hand, they must inform the controller of the same immediately in case of a breach. 

The notification to the authorities must include a list of elements and information about the breach that is mandatory to be informed to the authorities as well as in some cases, to the data subjects. Notification must include: 

• Description of the breach, including what data is compromised, how many data subjects’ data is at risk and all the other necessary details from the initial investigation and analysis.
• Contact details of the data protection officer in charge as a point of information of the incident. 
• Risks and consequences that could potentially harm the privacy and security of the data subjects. 
• Measures taken or planned to be taken to mitigate those risks to as minimal as possible. 

Compliance with Article 33 is ensured only when there is adequate and bonafide documentation about the personal data breach that includes almost all of the above elements. 

Article 34 of the Regulation sets out the conditions under which informing a data subject would be mandatory or would fall as an exception. When there is a risk to the rights and freedoms of a data subject due to the events in a breach, a controller is bound to inform a data subject about such a breach including most of the details mentioned under Article 33, excluding the general descriptions. This has to be done in a way that can clearly inform the data subject about the breach in a simple, straightforward way. 

Although, there are some exceptions as to the onus of notifying the data subject about a data breach, some of the situations where it may not be required anymore are – when measures to mitigate the risks to unauthorised access have been adopted by making the data at risk, unintelligible; when other measures have been taken by the controller and the risks posed earlier are not likely to ‘materialise’; or when a disproportionate effort, as in going out of the way to possibly multiple hundred data subjects would be involved, making public communication or notification of a breach, a rather feasible solution.

Incident Response and Management in India

The proposed Personal Data Protection Bill, 2019, currently undergoing discussions under a panel of the Parliament and awaiting the status of an Act, brings out a new wave of guidelines and regulations for data security and privacy. It will replace the barely adequate and scanty rules under the IT Act for data protection with laws focused purely on the same having at the very least, a global standard. Getting straight to the event of a data breach, the Bill has several provisions governing such breach and certain guidelines to follow for every data fiduciary. 

Section 25 of the Bill includes everything related to the reporting of a personal data breach. Where a breach is even ‘likely’ to put a principal’s data at risk, every fiduciary is mandated to report such breach to the data protection authority set up under the Act. The notice of the same has to include the nature of the data susceptible to risks from the breach, the number of data principals whose data has been compromised, potential risks and the measures being taken by the data fiduciary as a response to the breach. 

The notice of the breach has to be reported to the Authority within the specified time period and upon receiving such notice, it is on the Authority to determine whether a notice shall be given to the data principal as well, based on the severity or nature of the breach. The Data Protection Authority may also give out, where necessary, guidelines and instructions to the data fiduciary for remedying the effects of a data breach. The Authority, additionally, holds the power to direct a fiduciary to post on its website, details of the breach, describing the incident elaborately with the same contents as the notification to the Authority and, the Authority itself is entitled to post about the incident as well. 

Section 27 and Section 28 may not directly fall under the nomenclature of incident response but it can prove to be more helpful than expected. Section 27, which mentions data protection impact assessments and their elements, also includes what should consist of such an assessment. That in turn, can help pre-determine the pre-defined potential risks and the immediate as well as long term measures to remedy them. When coupled with the guidelines under Section 28 mentioning the Maintenance of Records, which includes documentation of all the practices adopted by the organization in the processing of the data, the combination creates a huge impact on how an incident is responded to, as the planning and analysis are conducted only based on the existing and updated state of practices of a fiduciary’s data protection and security system. 

Section 32 of the Bill describes the grievance redressal procedure by the data fiduciary which describes the protocols and mechanisms that shall be in place for any concerns of the data principals, which may also include events of personal data breach and the grievances of the fiduciary related to the same. 

LawSikho has created a telegram group for exchanging legal knowledge, referrals and various opportunities. You can click on this link and join:

https://t.me/joinchat/J_0YrBa4IBSHdpuTfQO_sA

Follow us on Instagram and subscribe to our YouTube channel for more amazing legal content.