Incident Management Information Dynamics Page  1

Information Incident  Management Policy

Document Summary


Information Dynamics India 
Incident Management Policy
Compliance To:
ISO 27001:2013 and ISO 20000:2011




Prepared By
1 st  November 2018
Information Dynamics
29 th   2019
Information Dynamics
24 th  December 2020

Document Review History

Reviewed By



29 th  December 2019
26 th  December 2020

Incident Management Information Dynamics Page  2

1. Purpose of the Incident Response Plan 
An   Incident   Response   Plan   is   required   in   order   to   bring   needed   resources   together  in   an   organized   manner   to   deal   with   an   adverse   event   related   to   the   safety   and  security   of   Organization’s   Business   &   Information   Assets.   This   adverse   event  may   be   malicious   code   attack,   unauthorized   access   to   Organizational   systems,  unauthorized   utilization   of   Organization   services   in   denial   of   service   attacks,  general misuse of systems, or hoaxes.
2. Purpose of the Incident Response Team 
The purpose Incident Response Team to: 
Protect Organizational Information assets, 
a central organization to handle incidents 
Comply with (government or other) regulations, 
Prevent the use of system attacks against other systems  (which could cause us to legal liability), 
the for negative exposure.
ISO 27001:2013 Domain Reference: A.16 – Information Incident Management

ISO 27001:2013 Reference


and procedures
Reporting security events


information security weaknesses
Assessment of decision on information security events


Response to information incidents
from security incidents


Collection evidence

ISO 20000:2011 Domain Reference: 6.6.3 – security changes and incidents
3. Scope 
The   scope   of   the   policy   will   be   applicable   to   all   activities   under   the   scope   statement   of  Information Dynamics.

Incident Management Information Dynamics Page  3

Policy Controls

4. Classification 
Security   incidents   will   be   classified   according   to   incident   catego r ies   and   severity  of incident. Incide n t re s will  b e based on classification.
A.  Incident Categories
The   f ollowing   categ o ri e s   will   be   u se d   to   desc r ibe   IT   secu r ity   incide n t s   a Information   Dynamics.   A   single   incident   m ay   have   several   different  categories.
1. Confidential data exposure
Customer details
Credit Card information
2. Criminal activity/investigation
Search or other court order
Litigation hold request (ala e-Discovery)
Online theft, fraud
Threatening communication
Physical theft, break-in
3. Denial of Service
Single or distributed (DoS or DDoS)
Inbound or outbound
4.  Digital Millennium Copyright Act (DMCA) violation ( if exists )
Official DMCA notification from copyright owner or legal  representative
distribution of copyrighted or licensed material  (movies, music, software, games)
Illegal copyrighted or licensed material 
5. Malicious code activity
Worm, virus, Trojan
6. violation
The Organization’s policy violation
Violation of code conduct
Personnel action/investigation 
7. activity
Management Information Dynamics Page  4

Port scanning
vulnerability scanning
Unauthorized monitoring
8. Rogue server or service
Rogue file/FTP server for music, movies, software,  etc.
Phishing scam web server
Botnet controller 
9. Spam source
Spam relay
Spam host
Computer on a block list 
10. Spear Phishing
e-mail targeting a relatively large number of <Name  of the Organization> e-mail addresses
11. Unauthorized access
Abuse of access privileges
Unauthorized access to data
Unauthorized login attempts
Brute force password cracking attempts
Stolen password(s)
12. Un- vulnerability
Vulnerable operating system
Vulnerable application
Vulnerable web site/service
Weak or no password on an account 
13. Web defacement
Defacement of web site
post to Bank’s comments/ section
Redirected web site 
14. Un-authorized network access
LAN connection
15. No Incident False-positive
When investigation of activity finds no  evidence of a security incident
B.  Incident Severity
An   incident   will   be   categorized   as   one   of   three   severity   levels.   These   severity  levels   are   based   on   the   impact   to   the   organization   and   can   be   expressed   in  terms   of   financial   impact,   impact   to   manufacturing,   impact   to   sales,   impact   to  company’s   image   or   impact   to   trust   by   company   customers,   etc.    Following  table   provides   a   listing   of   the   severity   levels   and   a   definition/description   of  each severity level.
Incident Management Dynamics Page  5

Severity Level

Incident where the impact is minimal. Examples are harmless email  SPAM, isolated Virus infections, etc.
Incident where the impact is significant. Examples are a delayed  ability order or manufacture [Product Name], delayed delivery of  critical mail or EDI transfers, etc.
Incident the impact severe. Examples are a disruption to the  or sales processes, company’s of  confidential information has been compromised, a virus 
or has become wide spread and is affecting over 30 percent of  the employees, or Executive management 
has reported it.

5. Responding To An Incident
Six stages of response are described below:
4.1 Preparation
One   of   the   most   important   facilities   to   a   response   plan   is   to   know-how   to   use   it  once   it   is   in   place.      Knowing   how   to   respond   to   an   incident   BEFORE   it   occurs  can save valuable and effort the long run. 
4.2 Identification 
Identify   whether   or   not   an   incident   has   occurred.    If   one   has   occurred,   the  response   team   can   take   the   appropriate   actions.   The   approach   to   the  Identification Stage involves:
1) Validating the incident
2) an incident has occurred, identify its nature
3) Identifying and protecting the evidence
4) Logging and reporting the event incident.
When   a   staff   member   notices   a   suspicious   anomaly   in   data,   a   system,   or   the  network,   he   or   she   begins   this   identification   process   or   immediately   notify   the  concerned person(s).
4.3 Containment 
It   involves   in   limiting   the   scope   and   magnitude   of   an   incident.   Because   so  many   incidents   observed   currently   involve   malicious   code,   incidents   can  spread   rapidly.    This   can   cause   massive   destruction   and   loss   of   information.  As   soon   as   an   incident   is   recognized,   immediately   begin   working   on  containment.   A   decision   on   the   operational   status   of   the   compromised   system  itself will be made. Whether this system should be:
1) Shut down entirely
2) Disconnected the network or 
Incident Management Information Dynamics Page  6

3) Be   allowed   to   continue   to   run   in   its   normal   operational   status   (so  that   any   activity   on   the   system   can   be   monitored)   will   depend   on  the to threatened by the incident.
4.4 Eradication 
Removing   the   cause   of   the   incident   can   be   a   difficult   process.   It   can   involve  virus   removal,   conviction   of   perpetrators,   or   dismissing   employees.   Should  follow good practices:
1) Determine the Cause and Symptoms 
Use   information   gathered   during   the   containment   phase   and   collect  additional   information.    If   a   single   attack   method   cannot   be  determined list and rank the possibilities. 
2) Improve Defenses 
Implement   appropriate   protection   techniques   such   as   firewalls  and/or   router   filters,   moving   the   system   to   a   new   name/IP   address,  or   in   extreme   cases,   porting   the   machine's   functions   to   a   more  secure operating system. 
3) Perform Vulnerability Analysis 
Use   of   vulnerability   analysis   tool   to   scan   for   vulnerable   systems  that are connected to affected systems.
4.5 Recovery and Closure
Restoring   a   system   to   its   normal   business   status   is   essential.   Information  Security   Office   reviews   the   tracking   system   and   closes   tickets   when  appropriate.
Once   a   restore   has   been   performed,   it   is   also   important   to   verify   that   the  restore   operation   was   successful   and   that   the   system   is   back   to   its   normal  condition. 
4.6 Follow-up
Some   incidents   require   considerable   time   and   effort.    It   is   little   wonder,   then,  that   once   the   incident   appears   to   be   terminated   there   is   little   interest   in  devoting   any   more   effort   to   the   incident.    Performing   follow-up   activity   is,  however,   one   of   the   most   critical   activities   in   the   response   procedure.    This  follow-up   can   support   any   efforts   to   prosecute   those   who   have   broken   the   law.  This   includes   changing   any   company   policies   that   may   need   to   be   narrowed  or be changed altogether.
6. Organization
Incident Management Information Dynamics Page  7

To   adequately   respond   to   an   intrusion   or   incident,   predetermined   teams   will  participate   depending   on   the   incident   characteristics.   As   the   situation   develops   and  the   impact   becomes   more   significant,   the   various   teams   will   be   called   to  contribute. Figure 1 depicts Incident Response organization .
7. Escalation Levels
Whenever   the   impact   of   the   incident   increases   (severity   level   increases)   the  escalation   process   will   be   invoked   to   involve   all   appropriate   resources.   Incidents  should   be   handled   at   the   lowest   escalation   level   that   is   capable   of   responding   to  the   incident   with   as   few   resources   as   possible   in   order   to   reduce   the   total   impact,  and   to   keep   tight   control.   Following   table   defines   the   escalation   levels   with   the  associated team involvement.
Escalation  Level
Affected Team(s)
Technical Assessment Team
Normal Operations. 
groups monitoring for alerts  from various sources
Technical Assessment Team
Incident Response Coordinator
Communication Team
A threat been discovered. 
Determine action to take.  Message employees of required actions if  necessary.

Incident Management Information Dynamics Page  8

Incident Response Management
Incident Response Coordinator
Technical Assessment Team
Technical Support Team
Communications Team
A threat has manifested itself. 
Determine course of action for containment  and eradication. Message employees of  required actions if necessary.
Incident Management
Response Coordinator
Extended Team
Technical Assessment Team
Support Team
Communications Team
Incident Support  Team
Threat is or impact is  significant.
Determine course of action containment  and eradication. Message employees.  Prepare to take legal action for financial  restitution etc.

8. The Process
The   Incident   Response   Process   is   an   escalation   process   where   as   the   impact   of   the  incident   becomes   more   significant   or   wide   spread,   the   escalation   level   increases  bringing   more   resources   to   bear   on   the   problem.   At   each   escalation   level,   team  members   who   will   be   needed   at   the   next   higher   level   of   escalation   are   alerted   to  the incident so that they will be ready to respond if and when they needed.
Management Dynamics Page  9

9. Responsibilities
Incident Management Information Dynamics Page  10

A   person(s)   must   be   formally   assigned   the   responsibility   to   create   and   distribute  security incident response and procedures to the personnel.
Area Responsible : Information Dynamics 
Manager : Soundar / Shaik 
Security Team : Sankar / Linda
CAUTION :   No   staff   member,   except   the   designated   Information  Security   personal   has   authority   to   discuss   any   security   incident   with   any  person(s) outside Information Dynamics.

10. Incident Response Plan Coverage
The response plan must include at a minimum the following
Roles, responsibilities, communication strategies in event a  compromise.
Coverage and responses for all critical system components.
Notification, at a minimum, credit and acquirers.
for business continuity post reference or  of response procedures card associations.
of legal for reporting compromises.
Data and of Critical systems 
11. Incident Response Mechanism
The   incident   response   plan   must   define   an   incident   escalation   process.   It   should  pre-define   the   personnel   responsible   for   immediate   incident   response   and   the  persons   to   whom   the   incident   should   be   escalated   incase   of   incident   remaining  unresolved.
[ Reference : Section7. Incident Response Process]
12. Testing of Incident Response Plan
The   incident   response   plan   must   be   tested   at   least   once   annually.   All   testing  results   must   be   documented   and   the   incident   response   plan   must   be   changed  depending on the testing results.
[ Reference : Doc - <Security Incident Test Plan Procedure_v1]
Incident Management Information Dynamics Page  11

13. Response Support
There   should   be   designated   security   personnel   who   should   be   available   24/7   to  respond   to   unauthorized   activity,   critical   IDS   alerts,   and/or   reports   of   unauthorized  critical system or content changes.
Area Responsible : Information Dynamics 
Manager : / Shaik 
Information Security Team : Sankar / Linda
14. Training
The   staff   providing   incident   response   must   be   appropriately   trained   to   respond   to  security   breaches.   Training   requirements   must   be   accessed   on   the   basis   of   incident  response plan and performance of incident personnel.
15. Alerts
An   alerting   mechanism   must   be   in   place   to   notify   the   incident   response   personnel.  The   alerts   to   be   sent   to   incident   response   personnel   must   include   alerts   from  intrusion detection, intrusion prevention, file integrity monitoring systems.
Typical   symptoms   of   computer   security   incidents   include   any   or   all   of   the  following: 
A system alarm similar indication from an intrusion detection tool
Suspicious entries in or accounting 
Accounting discrepancies 
Repeated unsuccessful attempts 
Unexplained, new user accounts 
Unexplained new or unfamiliar names 
Unexplained   modifications   to   file   lengths   and/or   dates,   especially   in  system files 
Unexplained   attempts   to   write   to   system   files   or   changes   in   system  files
Unexplained modification or deletion of data 
Denial/disruption   of   service   or   inability   of   one   or   more   users   to   login  to an account 
System crashes 
Poor system performance 
Operation of a program sniffer device to capture network traffic 
Remote   requests   for   information   about   systems   or   users   (e.g.,   social  engineering)
Unusual   time   of   usage   (many   computer   security   incidents   occur   during  non-working hours) 
Incident Management Information Dynamics Page  12

An   indicated   last   time   of   usage   of   a   user   account   that   does   not  correspond to the actual time of usage for that user 
Unusual   usage   patterns   (e.g.,   programs   are   being   compiled   in   the  account   of   a   user   who   does   not   know   how   to   program,   an   escalation   in  by a single )
16. Incident Response Plan Updating
There   must   exist   a   process   to   modify   and   evolve   the   incident   response   plan  according   to   lessons   learned   and   to   incorporate   industry   developments.   Annual  Security   Incident   Response   Test   Procedure   can   be   used   for   this   purpose.   Any  lesson-learned   during   the   test   phase   must   be   incorporated   into   the   Production  Procedure. 
17. Incident Contacts
A   list   of   contact   information   of   the   incident   response   personnel   should   be  maintained. The contact information must enable to contact 24/7.
1. Internal group/officer incident response team
Chennai Police Cyber Cell
Tel: 044 - 22641261 & email -

18. Un-Authorized Wireless detection
Detection   of   any   rogue   wireless   device(s)   is   considered   as   a   Critical   Incident.  Following action must be taken immediately
1. The   head   of   the   network   infrastructure   and   the   network   team   must   be  alerted.
2. A   physical   walkthrough   must   be   conducted   to   identify   the   physical  location of the point.
3. The   wireless   access   point/device   must   be   disconnected   from   the  organization network.
4. The   wireless   access   point/device   logs   must   be   recovered   from   the   device  to analyze the network traffic for any cardholder data breach.
Information Technology Department
Policies & Procedures

Page  13

Incident Response Matrix
Incident  Severity
Characteristics ( more condition present  determines severity)
Response Time
Incident Manager
Whom notify

1) Significant impact on a large number of systems and/or people

 Security Manager

 IS Team

2)  confidential data



3)  Adversely impacts a critical enterprise service



4)  Significant and immediate threat to safety




5)  High probability of propagating to a large of other on or  bank's and causing significant disruption




1)  Adversely impacts a moderate number of systems and/or people

 Security Manager

 IS Team

2)  Adversely a non-critical enterprise system or service

3)  Adversely impacts a departmental scale system service


4)  Moderate risk of propagating and causing further disruption

2 Hours

1)  Adversely impacts a very number of non-critical individual systems,  services, or people

 Security Manager

 IS Team


2)  Little risk of propagation and further disruption

4 Hours



Information Technology Department
Policies & Procedures

Page  14

Associated Documentation
Information Security incident management procedure
Incident Response Process
Incident Training
Security Incident management plan procedure