Page 1 of 1

Incidence Response

1. Purpose

1.1 This policy defines the framework for the management of information security incidents at , including reporting of incidents, escalation procedures, and actions to contain the damage and recover systems and follow-up investigative and corrective actions.

2. Scope and Applicability

2.1 The procedures outlined in this document apply to all incidents involving all full-time/third-party/contractual employees, vendors/clients of and its information assets.
2.2 All incidents causing breaches of confidentiality, integrity and availability of asset will be addressed using this procedure.

3. Responsibility

3.1 IT team, Incident Response Team (IRT), Information Security Manager (ISM), HR, and all end users are responsible for the execution of various procedures included in this document.

4. Incident Management Policy

4.1 Information Security Incidents
4.1.1. An event is an identified occurrence of a system, service, or network indicating a possible breach of information security policies, procedures, and safeguards or a previously unknown situation that may be relevant from the point of view of security. An event will be termed as an incident if it is considered to have an “adverse” impact on the system/IT infrastructure or through pre-positioned criteria that describes the circumstances under which events will automatically be deemed adverse.
4.1.2. An event will be an incident when it is analyzed and classified to be adverse by the incident response team.
4.1.3. An Incident is an occurrence of any exceptional situation that could compromise the Confidentiality, Integrity, or Availability of Information and Information Systems of . It is related to exceptional situations or a situation that warrants the intervention of senior management, which has the potential to cause injury or significant property damage.
4.1.4. All events shall be reported in a timely manner as per procedures for event reporting and corrective actions shall be taken immediately as per procedures for incident response to avoid the recurrence of such events in the future.
4.1.5. All shall also be made aware of the procedures for reporting different types of incidents (like a security breach, threat, weakness, or malfunction) that might have an impact on the security of assets.
4.2 Management of Information Security Incidents and Improvements
4.2.1. shall assign an incident response team for handling and management of information security incidents.
4.2.2. The lessons learned from the incidents types, impacts, and costs shall be documented for future reference

5. Incident Management Procedures

5.0.1 Who is the incident manager at ?
5.1.1. has been identified and deputed as Incident Manager. The incident Manager shall be responsible for initiating actions to be taken in case of an incident. He/ she shall also do a review and analysis of the incidents that happened over a period of time. The incident Manager shall consultant (CTO) as required.
5.2 Incident Response Team (IRT)
5.2.1 The Incident Response Team (IRT) should be formed to address any incidents and initiate immediate action to resolve the same. Such teams should be formed ad hoc based on the severity and impact of the incidents. The Incident Response Team should issue guidelines to address potential threats/risks arising out of incidents.

6. Incident Reporting

6.1. Any unusual event shall be reported by the user, based on its nature.
6.2. All critical IT events shall be reported to the IT team, IT team shall answer, evaluate, and prioritize the incoming telephone, e-mail, and in-person requests for assistance from users experiencing problems with hardware, software, networking, security, and other computer-related technologies;
6.3. Once the event is classified as an incident, the following will be done:
6.3.1. Record the incident in the incident register;
6.3.2. Review and analyze the incident;
6.3.3. Try to resolve the same based on past experience.
6.3.4. Escalate problems to IT Support Vendor (if required);
6.3.5. Escalate any security Incident to ISM promptly (if required);
6.3.6. Call software and hardware vendors to request service regarding defective products (if required).
6.4 All critical non-IT incidents shall be reported to Incident Manager. The incident Manager, shall do the following:
6.4.1. Categorize the incident as Operational Incident or Security Incident.
6.4.1.1. If Operational, Escalate to Client personnel
6.4.1.2. If Security, try to resolve the incident or escalate to (CTO) (if required);
6.4.2. Escalate the incident to law enforcement agency depending on its criticality, (if required);
6.4.3. Collate information related to Non-IT incidents from all the registers and maintain a history of the same;

7. Incident Classification and Escalation

7.1. Incidents are classified based on:
a. Possible Business Impact
b. Maximum tolerable downtime
7.2. The Incident Manager shall classify the incidents as mentioned in 7.1. The incident Manager shall assign the classification based on the information collected from the person reporting the incident. Based on the Severity and Impact, the Incident Response Team (IRT) will be formed.
7.3. What is 's Incident Classification Plan?

8. Incidence Response

8.1 Incident containment
8.1.1. The Incident Manager or IRT shall visit the location (place, computer, server, etc) to collect further details immediately and take appropriate steps to isolate and contain the incident if it is capable of spreading to other assets.
8.1.2. If the Incident Manager or team is unable to identify the probable cause and the probable resolution, it should contact the vendors or any other appropriate personnel.
8.1.3. In certain cases, an incident (e.g. internal fraud) needs to be reported to the law enforcement agencies. In such cases, a legal advisor shall be consulted.
8.1.4. In special circumstances, the IRT should decide when and why an investigation should be conducted, and whether to involve law enforcement agencies. Privacy issues need to be considered prior to such investigations.
8.2 Evidence Management (Collection of Evidence)
8.2.1. Evidence collected and analysed during incident response shall be preserved and well protected as they may be intangible and subject to easy modification without trace.
8.2.2 Evidence can be collected from various sources, including but not limited to:
a. Telephone Records;
b. Audit Trails;
c. System Logs;
d. System Backup;
e. Witnesses;
f. E-Mails;
g. Results of surveillance etc.
8.3 Corrective Action and Recovery
8.3.1. The Incident Response team must prepare the corrective action plan for the incident. The action plan, though specific to each case, should typically cover the following:
a. Facts and explanation/reasons for the incident ;
b. Corrective action to be taken;
c. Estimated cost of implementing the corrective action (if applicable);
d. Estimated time frame, start date, and end date;
e. Personnel responsible for taking the action.
8.4 Follow up and lessons learned
8.4.1. After each incident a lessons-learned exercise must be conducted by the Incident Response team and should be documented in the incident register.
8.4.2. The Incident Response team shall identify the reasons for the occurrence of the incidents and actions to prevent such incidents from recurring needs to be defined and implemented accordingly.
8.4.3. (CTO) in consultation with Incident Manager, shall review and analyze the incidents for peculiar trends and prepare a preventive action plan accordingly. This trend analysis should be reported and discussed with management.
8.5 Incident documentation: Both IT and Non-IT incidents are registered in the Incidence Register.
8.5.1. The incident should be documented to clearly identify
a. Type of incident (IT or Non-IT)
b. Severity of the incident
c. The name of the person who reported the incident and the personnel involved in resolving the incident.
d. The incident description and the solution implemented
e. The time taken to identify and resolve an incident should be documented.

8.6. Do you have an Incidence Response Plan in place?

9. Exceptions

Exceptions shall not be universal but shall be agreed upon on a case-to-case basis, upon official request made by the information owner. These may arise, for example, because of local circumstances, conditions, or legal reasons existing at any point in time.
All exception requests shall be submitted to (CTO). These shall be submitted through an email and to be approved by (CTO).

10. Disclaimer

reserves all rights and are the exclusive owner of all intellectual property rights over this Policy document. This document shall not, either in part or in full, be reproduced, published, copied, displayed, distributed, transferred, or stored in any media (such as hard disks, USB Drives, Pen Drives, Memory Cards, CDs, DVDs), and/or captured or transmitted through by any means (such as electronic, digital, mechanical, photocopying, recordings, video and film or photographs and otherwise) by any person without prior consent from the ISM. This Policy and procedure document is made available with ISM and/or any other forum as decided by the management of . Anything not specifically stated in this Policy and procedure document shall not be considered as implied in any manner.
For any clarifications related to this Compliance Policy and procedure document with respect to its interpretation, applicability, and implementation, please write to the ISMS team. At dpo@.com

11. Enforcement

11.1. This policy and procedure are applicable to all the employees of the company who have access to and use the information assets and IT assets as listed in the Information Asset register which has been created for .
11.2. Anyone found to have violated this policy will be subject to a process that will determine if the violation is just a process non-compliance issue that requires addressing or also includes ethical violations In the event of only the former, non-compliance could be issued by an internal auditor which would require corrective/preventive actions.
11.3. In the event of the latter, the ethical/regulatory concern process will be invoked to decide whether an ethical/security violation has occurred and to decide on appropriate disciplinary actions as per the Disciplinary procedure of .
11.4. Management’s interpretation of the clauses in this procedure shall be final and binding. 11.5. Management reserves the right to alter or amend any clause in this document at any time as per its discretion