Incident Response Plan

1.
Incident Response Plan
GAMA
Jeddah-Saudi Arabia
Approval Date:
17/Apr/2024
Prepared by:
Ghofran Ahmed Alkhaldi
The information contained in this report was derived from proprietary data provided by:
GAMA Ltd
1.0
Contents
1.0 Overview............................................................................................................................................5
2.0 Purpose...............................................................................................................................................5
3.0 Scope..................................................................................................................................................5
4.0 Incident Response Team....................................................................................................................5
4.1 Roles and Responsibilities...............................................................................................................5
4.1.1 Information Response Coordinator (IRC) – My Company Information Security Officer...6
4.1.2 Incident Response Team (IRT) / IT Steering Committee....................................................6
4.1.3 Extended Team.....................................................................................................................6
4.1.4 Board of Directors................................................................................................................6
5.0 Incident Response Preparation...........................................................................................................6
5.1 Process (Governance, Documentation, and Risk Management).....................................................6
5.2 Technology......................................................................................................................................6
5.3 People..............................................................................................................................................6
6.0 Incident Response Plan......................................................................................................................7
6.1 Categories of Information................................................................................................................7
6.1.1 Public....................................................................................................................................7
6.1.2 Internal Use Only.................................................................................................................7
6.1.3 Confidential..........................................................................................................................7
6.1.4 Restricted..............................................................................................................................7
6.2 Incident Types.................................................................................................................................7
6.2.1 Specific Information Technology Incident...........................................................................7
6.2.2 Service Provider Incident.....................................................................................................7
6.2.3 Physical Theft or Loss Incident............................................................................................8
6.3 Threat Intelligence Program............................................................................................................8
6.4 Information Technology Incident Identification Matrix.................................................................9
6.4.1 Incident Severity Levels.......................................................................................................9
6.4.2 Incident Identification Matrix.............................................................................................10
6.5 Escalation Procedures....................................................................................................................11
6.5.1 Escalation Level 1 - Minimal Escalation............................................................................11
6.5.2 Escalation Level 2 - Low Escalation..................................................................................12
6.5.3 Escalation Level 3 - Medium Escalation............................................................................12
6.5.4 Escalation Level 4 - High Escalation.................................................................................13
1.0
6.6 Procedures for Handling Specific Information Technology Incidents..........................................14

6.6.1 Malicious Code / Malware Incident...................................................................................14
6.6.2 Ransomware.......................................................................................................................15
6.6.3 Inappropriate Usage Incident.............................................................................................16
6.6.4 Inappropriate Usage Matrix................................................................................................17
6.6.5 Unauthorized Access Incident............................................................................................17
6.6.6 Denial of Service Incident (DoS).......................................................................................18
6.6.7 Multiple Component Incidents...........................................................................................19
6.7 Handling Service Provider Incidents.............................................................................................19
6.7.1 The Bankers Bank (IWEB)................................................................................................19
6.7.2 Fiserv EFT..........................................................................................................................20
6.7.3 <ATM Provider> - ATM Fraud.........................................................................................21
6.7.4 Fiserv Internet Banking......................................................................................................22
6.7.5 Cloud-based Software-as-a-Service providers...................................................................23
6.7.6 Corporate Account Takeover (CATO)...............................................................................24
6.7.7 Managed Technology Service Providers............................................................................24
6.8 Handling Physical Theft or Loss Incidents...................................................................................25
6.8.1 Unauthorized Access Incident............................................................................................25
7.0 Customer Information Definition.....................................................................................................26
7.1 Evaluation......................................................................................................................................26
7.2 Customer Notification...................................................................................................................27
7.3 Suspicious Activity Report............................................................................................................27
8.0 Incident Response Team Contact Information.................................................................................29
8.1.1 Incident Response Coordinator..........................................................................................29
8.1.2 Incident Response Team.....................................................................................................29
8.1.3 Extended Team...................................................................................................................29
8.1.4 External Support Contacts..................................................................................................29
9.0 Other Contact Information...............................................................................................................29
9.1 Government Agencies...................................................................................................................29
9.2 Technical.......................................................................................................................................29
9.3 Debit Cards....................................................................................................................................29
9.4 Internet Banking............................................................................................................................29
9.5 Nationwide Consumer Reporting Agencies..................................................................................29
9.6 Major Correspondent Banks..........................................................................................................29
1.0
9.7 Detailed Contact Information........................................................................................................30

10.0 Potential Breach Response Vendors................................................................................................30
11.0 Incident Response Form...................................................................................................................31
12.0 Sample Customer Notification Letter..............................................................................................33
Incident Response Plan My Company –
Incident Response Plan
1.0 Overview
My Company management understands not all threats to the Organization can be mitigated and a prudent
management practice is to have a comprehensive Incident Response Plan (IRP). A comprehensive Incident
Response Plan is necessary to ensure appropriate actions are taken in the event of an information security
incident.
2.0 Purpose
Incident Response is the process of planning, documenting, and communicating procedures to react to an
information security incident. Incident Response is necessary because, throughout the world, attackers frequently
compromise customer and business data. The following benefits are the results of having an effective Incident
Response capability:
1. Respond to incidents in a documented chronological order to ensure appropriate steps are taken.
2. Recover quickly and efficiently from information security incidents with a goal of minimizing loss or
theft of information and disruption of services.
3. Communicate promptly notifying customers and regulatory authorities if misuse of customer
information is reasonably suspected and/or has been confirmed.
4. Coordinate legal questions and/or business issues that may arise during incidents.
5. Enhance current operations by utilizing information gained during Incident Response to better
prepare for future incidents and provide stronger protection for information systems and data.
3.0 Scope
The scope of this Incident Response Plan is to document the most common or most probable types of incidents
and outline a framework for response actions. This plan will address both internal and external threats. It is
unrealistic to detail actions for every potential type of breach; however, the IRP has been designed to encompass
highly probable security incidents in a framework that can be customized for the specific incident. If an incident
occurs that is not specifically outlined, this plan will serve as a guideline for formulating the appropriate response.
This plan is also to be followed, as appropriate, if notification has been given by a service provider of a security
breach within their organization.
4.0 Incident Response Team
4.1 Roles and Responsibilities
The purpose of My Company’s Incident Response Team is to:
 Protect My Company’s Information assets.
 Provide a central organization to handle incidents.
 Comply with (government or other) regulations.
 Prevent the use of My Company’s systems in attacks against other systems (which could cause us to
incur legal liability).
 Minimize the potential for negative exposure.
This section will identify roles and responsibilities of each member of the IRT. The Information Security
Officer will be the managing member of this team, and all other members will provide support to the
Organization during an incident. The IT Steering Committee will be involved, following the incident, to
review reports and make any needed changes to the Information Security Program (ISP) to reduce the
likeliness of a repeat incident. The Board of Directors will review all reports and approve any changes to
the ISP. The CEO has been designated to handle all communications with the media; if the CEO is unable
to do this, the Chairman of the Board will designate another team member.
For Incident Response Team Contact Information, see
Internal Information 5 Powered by TRAC™

Do Not Distribute © 2024 SBS Cybersecurity
Incident Response Team Contact Information in section 8.0

4.1.1 Information Response Coordinator (IRC) – My Company Information Security Officer
 Receive incident notifications.
 Report incident to appropriate management.
 Convene the Incident Response Team as required.
 Lead incident identification procedures.
 Lead or delegate incident handling procedures.
 Lead or delegate customer notification procedures.
 Compile Follow-up Reports for the IT Committee and Board of Directors.
 Conduct lessons learned meetings.
4.1.2 Incident Response Team (IRT) / IT Steering Committee
 Report incident to Information Response Coordinator (IRT).
 Assist in incident identification.
 Assist in incident handling procedures.
 Assist in customer notification procedures.
 Notify staff of incident and outcome of the Incident Response.
 Review Follow-up Reports.
 Integrate lessons learned information into Information Security Program (ISP).
 Inform Board of Directors of any changes in the ISP following the incident.
 Report incident to Information Response Coordinator (IRT).
 Assist in incident identification.
 Assist in incident handling procedures.
 Assist in customer notification procedures.
 Notify staff of incident and outcome of the Incident Response.
4.1.3 Extended Team
 Law Firm
 Insurance Agency
4.1.4 Board of Directors
 Review Follow-up Report.
 Review changes to the ISP.
5.0 Incident Response Preparation

My Company believes that implementing a strong, layered security program to prevent incidents from occurring is
a key component of an effective Incident Response Plan. The institution has established strong security controls
across the organization. These preventative controls are outlined by the following three major categories and
some key components of each:
5.1 Process (Governance, Documentation, and Risk Management)
• Information Security Program.
• IT Risk Assessment.
• Cybersecurity Assessment.
• IT Audit Program.
5.2 Technology
• Next-generation Firewalls.
• Firewall Intrusion Reports.
• Anti-Malware.
• Patch Management.
5.3 People

• Director/Senior Management cybersecurity training.

• Security Awareness Training (customer and employee).
• Ongoing education (role-based certification programs and schools).
• Social Engineering Testing (monthly).
6.0 Incident Response Plan
Determine the Category of Information from the options below and proceed to the Incident Type.
6.1 Categories of Information
6.1.1 Public
Public documents and information in the public domain, such as:
1. Advertising.
2. Press Statements.
3. Reports required to be published for public view.
6.1.2 Internal Use Only
Documents and information not containing sensitive customer information but not approved for
circulation outside the organization, such as:
1. Procedures.
2. Non-confidential policies and project plans.
3. Internal memos.
4. Reports.
6.1.3 Confidential
Documents and information that may or may not contain sensitive customer information, such as:
1. Accounting information.
2. Business plans.
3. System information.
4. Sensitive customer information.
6.1.4 Restricted
Highly sensitive information that if lost would result in serious financial damage or loss of credibility, such
as:
1. Reports of examinations.
2. Audits.
3. Investment strategies.
4. Data tapes.
5. Pending mergers of acquisitions.
6. Fraud investigations or reporting.
6.2 Incident Types
6.2.1 Specific Information Technology Incident
When an incident involves a specific IT-related system or application, follow the procedures in Section 6.6
Procedures for Handling Specific Information Technology Incidents. These procedures can also be used in
the event an incident is reported directly from an employee using this systems or applications.
6.2.2 Service Provider Incident
When an incident is reported to the Organization by a service provider, follow the procedures in Section
6.7 Handling Service Provider Incidents. All service providers included in this Incident Response Plan have
agreed to notify the Organization of any security incidents involving its customer information. These
procedures can also be used in the event that an incident is reported directly from Organization
customers using these services.

6.2.3 Physical Theft or Loss Incident
When an incident involves the physical theft or loss of an Information Technology system or information
storage device, follow the procedures in Section 6.8 Handling Physical Theft or Loss Incidents.
6.3 Threat Intelligence Program

The institution’s Threat Intelligence Program has been designed to identify sources that define and
explain today’s evolving threat landscape, document the sources of information and how they will be
used, and to assess and distribute threat information as applicable. Threat Intelligence may come from
internal or external resources and should provide the institution with actionable intelligence regarding
threats, how to mitigate specific threats or vulnerabilities, and who is responsible for actions against
known threats. The sources below are utilized for actionable intelligence and provide various reports and
detection methods.
Internal or
Threat Intelligence Source Website
External
Firewall Alerts https://perimeter.securityview.com Internal

Intrusion Prevension Sys-
https://perimeter.securityview.com Internal
tem (IPS) Alerts
FS-ISAC Standard Member-
https://www.fsisac.com/ External
ship
US-Cert https://www.us-cert.gov/ External
Infragard Portal https://www.infragard.org/ External
SBS Cybersecurity Blog https://sbscyber.com/ External
KnowBe4 Blog https://blog.knowbe4.com External

Brian Krebs on Security https://krebsonsecurity.com/ External

6.4 Information Technology Incident Identification Matrix

The ratings in table 6.4.2 indicate how likely a symptom matches a threat. Symptoms with a corresponding
high value are most likely caused by the threat listed in the above column heading. Careful comparison of all
symptoms of an event should identify which threat has occurred; and which actions should be taken. Actions
should be taken according to the reference column in table 6.4.2, to address that particular threat. Use the
following procedure to identify the threat:
6.4.1 Incident Severity Levels
An incident will be categorized as one of six (6) severity levels. These severity levels are based on the
impact to My Company and can be expressed regarding financial impact, impact to customer service,
impact to processing, impact to My Company’s image, impact to trust by My Company’s customers, etc.
Table 1 provides a listing of the severity levels and a definition/description of each severity level.
Severity Level Description

None No effect on any systems
Minimal Minimal impact on one to a few systems
Low Noticeable effect on one to a few systems (i.e., isolated Virus infections, etc.)
Incident where the impact is significant. Severe impact on a few systems or small
impact on a large number of systems or critical infrastructure. Examples are a de-
Medium
layed ability to deliver banking services or non-destructive malware on multiple
network segments.
Noticeable effect on a large number of systems or critical infrastructure. Exam-
ples are a disruption to the banking services, sensitive customer information has
High been compromised, a virus or worm has become widespread and is affecting
over 25 percent of the employees, or My Company Executive management has
reported it.
Severe effect on a large number of systems or critical infrastructure. Examples in-
clude the malware/ransomware infection of entire WAN, multi-vector attacks of
Critical the network (DDoS + social engineering), My Company proprietary or confiden-
tial information has been compromised, confirmed internal network compromise
or news of a major incident has been leaked to the media.
Table 6.4.1: Severity Levels

6.4.2 Incident Identification Matrix

The Incident Identification Matrix is designed to identify the top potential incidents to the institution, an
inherent risk score for each threat, potential symptoms that may lead to an identification of the incident,
and which systems stand to be affected by such an incident. All Incidents identified in the Incident
Identification Matrix should have corresponding response procedures outlined in the reference column.
Threat Score Potential Af-

Threat Reference Impact (I) Probability (P) Symptoms
(I * P) fected Systems
Device crashes, de-
Malicious Code In- Section vice slowness, Win- All Networked
Critical (5) Critical (5) 25
cident 6.6.1 dows errors, pop- Devices
ups, missing files
Files and folders are
all encrypted, net-
Section All Networked
Ransomware Critical (5) Critical (5) 25 work resources inac-
6.6.2 Devices
cessible, devices
crashes
Suspicious user be-
Unauthorized Ac- Section havior; firewall User worksta-
Critical (5) High (4) 20
cess 6.6.4 alerts; web filter tions, Servers
blocks
Suspicious user be- Customer Ac-
Corporate Account Section
High (4) Medium (3) 12 havior; unauthorized counts; Internet
Takeover 6.8.6
transactions Banking
Distributed Denial Device slowness, In-
Section All Internet-fac-
of Service (exter- Medium (3) Low (2) 6 ternet inaccessible,
6.6.5 ing Hosts
nal) website(s) down
Device slowness, ar-
Internal Denial of Section All Networked
High (4) Minimal (1) 4 eas of network re-
Service 6.6.5 Devices
sources inaccessible
Suspicious user be-
Section havior; firewall User worksta-
Inappropriate Use Low (2) Low (2) 4
6.6.3 alerts; web filter tions, Servers
blocks
Table 6.4.2: Incident Symptom Identification Matrix

6.5 Escalation Procedures

Not all incidents require the same level of response. Using escalation procedures will help employees of the
institution determine who should be involved and notified in the incident response process. Determining the
escalation level of an incident will also help incident responders prioritize incidents if more than one incident
occurs at a time. Each incident should be handled with as few resources as necessary to reduce the total
impact and to help maintain control of response resources.
The following matrix should be used to help determine the overall effect of an incident, the individuals and
teams that will be involved with remediating the incident, and a description of events.
Escalation
Level Affected Team(s) Description
Normal Operations. IT Staff monitoring for
Minimal (0) IT Staff
alerts from various sources
A threat has been discovered, determine
Low (1) IT Staff/Assessment Team defensive action to take. Message
employees of required actions if necessary.
A threat has manifested itself but is
contained to a minimal footprint (single or
Incident Response multiple devices or a network segment).
Determine course of action for containment
Management/Coordinator
Medium (2) and eradication. Message employees of
IT Staff/Assessment Team
required actions if necessary. Prepare for
Communications Team delivery any customer notification that may
be necessary. Notify appropriate authorities
of the incident.
Threat is widespread or impact is
Incident Response significant. Determine course of action for
containment and eradication. Message
Management/Coordinator
employees. Prepare to take legal action for
High (3) IT Staff/Assessment Team
financial restitution etc. Prepare for delivery
Communications Team
any customer notification that may be
Extended Team necessary. Notify appropriate authorities of
the incident.
Table 6.5: Escalation Levels
6.5.1 Escalation Level 1 - Minimal Escalation

1. IT Staff/Assessment Team
 Monitors all known sources for alerts or notification of a threat. These sources are listed in
Section 6.3.1 Key Risk Indicators
2. No Status Report required.
6.5.2 Escalation Level 2 - Low Escalation
1. Incident Response Plan Implementation (a threat has been realized)
 IT Staff/Assessment Team.
o Determine initial defensive action required.

o Notify the Incident Manager/ Information Security Officer.
o If employee action is required, such as updating anti-virus files, notify the IT
Manager.
o If employee action required, message employees of required action.
 Incident Response Coordinator.
o Receive and track all reported potential threats.
o Escalate Incident Response to Level 2 if a report is received indicating that the
threat has spread to multiple systems or hosts.
o Alert relevant staff and applicable support organizations of the threat and any
defensive action required.
o Consider additional resources based on escalation potential.
o Ensure documentation process is ongoing (Chronological Log of Events).
o Begin the Containment and Eradication phase.
2. Status Report / Communication Report.
 Senior Management / Board of Directors (As appropriate).
6.5.3 Escalation Level 3 - Medium Escalation
1. Incident Response Plan Implementation (a threat has affected multiple systems or hosts).
o Direct the Incident Response Support/Technical team to:
 Set up communications between all Incident Response staff.
 Keep staff updated as incident progresses.
o Determine when the risk has been mitigated to an acceptable level.
o Begin Containment and Eradication phase of Incident Response Plan.
 Goal = stop the further spread or infection to other systems or hosts.
o Continue maintaining the Chronological Log of Events.
o Post chronological status messages and updates to staff and My Company
executive management.
o Notify Executive Management of the incident severity level and affected systems
or hosts.
o Continue to monitor all known sources for alerts looking for further information
or actions to take to eliminate the threat.
o Continue reporting status to the Incident Response Manager/Coordinator for the
chronological log of events.
o Monitor effectiveness of actions taken and modify them as necessary.
o Status Incident Response Management/Coordinator on effectiveness of actions
taken and progress in eliminating the threat.
o Continue actions to eradicate the threat as directed by Incident Response
Management and the Technical Assessment team.
2. Daily Status Report.
 Executive Officer(s).
 Senior Management / Board of Directors (As appropriate).
6.5.4 Escalation Level 4 - High Escalation.

1. Incident Response Plan Implementation (a threat has affected the majority of systems or hosts
and/or customer information has been compromised, exfiltrated, or destroyed).


o Direct the Incident Response Support/Technical team to:
 Set up communications between all Incident Response staff .
 Setup a command center to centralize the coordination and execution of the Incident Response
Plan.
 Initialize an incident voice mailbox where status messages can be placed to keep My Company
personnel statused.
o Alert the Extended Team of the incident notifying them of the Severity Level.
o Begin Containment and Eradication phase of Incident Response Plan.
 Goal = stop the further spread or infection to other systems or hosts.
o Determine when the risk has been mitigated to an acceptable level.
o Notify Executive Management regarding decisions on SAR filings, law enforcement
notification, and/or regulatory notification.
 Extended Team.
o Contact local authorities as directed by Executive Management.
 If local authorities are called in, make arrangements for them to be
allowed into the command center.
o Initiate Customer Notification if deemed appropriate, either for operational
purposes (if a customer-facing product is affected) or breach purposes.
o Ensure that all needed information is being collected to support legal action or
financial restitution.
 Communication Team.
o Establish a communication channel for My Company staff as directed by Incident
Response Management/Coordinator.
o Prepare Communications to Customers as directed by Executive Management.
o Continue to monitor all known sources for alerts looking for further information
or actions to take to eliminate the threat.
o Continue reporting status to the Incident Response Manager/Coordinator for the
chronological log of events.
o Monitor effectiveness of actions taken and modify them as necessary.
o Status Incident Response Management/Coordinator on effectiveness of actions
taken and progress in eliminating the threat.
o Continue actions to eradicate the threat as directed by Incident Response
Management and the Technical Assessment team.
2. Daily Status Report.
 Executive Officer(s).
 Human Resources Department.
 Board of Directors.
 Media Contact (as applicable).
 Senior Management / Board of Directors.
6.6 Procedures for Handling Specific Information Technology Incidents

6.6.1 Malicious Code / Malware Incident
1. Report the incident to the Incident Response Coordinator (IRC).
2. Identify the incident.

o If malicious code / malware is suspected, do not unplug computers or servers from the
power source, but IMMEDIATELY disconnect from the internet (this is typically the blue
cable connected to the back of your computer) to stop the malicious code / malware from
spreading.
o Begin the documentation process. Make sure evidence is being captured throughout.
Complete Incident Response Form (Section 11.0 Incident Response Form).
o Determine the scope of the malicious code / malware infection. Is it on one computer,
multiple computers, or the entire network?
 Are the affected network segment(s) able to be shut down or disconnected?
o Categorize the incident based on severity. Responsibilities should be outlined for different
members of the organization at each level of incident severity.
 Who needs to be involved at each level?
 When does senior management and the Board get notified?
 When and how do we communicate with customers?
 What sort of status reports need to be kept and on what frequency?
o Determine the potential for the incident to escalate to a higher severity level.
 Will external parties (i.e. digital forensics or additional resources) be required?
o Notify appropriate law enforcement, third parties, or regulatory agencies.
3. Contain the incident.
o Ensure the process is being thoroughly documented.
o If possible, take a digital forensic image of the infected device(s).
o Investigate the strain of malicious code / malware. There are mitigation tools out there
that may immediately provide relief, containment, or eradication of the malicious code /
malware.
o Determine if it’s more appropriate to restore from backups or work to eradicate the
particular strain of malicious code / malware.
 This decision should depend on Recovery Time Objective (RTO) and Maximum
Allowable Downtime (MAD) measurables.
 If restoring from backups, be sure to scan backups for malicious code / malware
VERY THOROUGHLY. Many forms of malicious code / malware employ delayed
attacks, waiting 30-45 days before encrypting computers or files. Be cautious as
this would mean that the malicious code / malware is also on the backups, and
will immediately re-deploy upon restoration unless remediated.
o Watch the network for exfiltration of data. Many forms of malicious code / malware will
exfiltrate data for sale or use at a later time.
4. Eradicate the incident.
o Ensure all workstations, servers, and devices are THOROUGHLY scanned (and rescanned) to
ensure they are free from infection before re-deploying anything back to a production
network.
o Consider a digital forensics investigation to determine the scope, depth, breadth, and
causes of the attack.
o Mitigate the exploited vulnerabilities for other hosts on the institution’s network.
5. Recover from the incident.
o Analyze results of the digital forensic investigation (if applicable).
o Determine if any confidential customer information was accessed. Notify as necessary.
o Check with insurance agency to determine if any losses are covered.
o Create a post-incident report and hold a lessons-learned meeting with key staff to
determine necessary improvements to the Incident Response Plan.
o Share information with FS-ISAC or other industry intelligence sharing communities (as
applicable/advised).
o Report to the FBI/Internet Crime Complaint Center (IC3) (if not involved already).
o Plan for future malicious code / malware incidents and test the plan periodically.
6. Document the incident.

o Fill out Incident Response Form.
o Report to the Board of Directors regularly.
6.6.2 Ransomware
o If ransomware is suspected, do not unplug computers or servers from the power source,
but IMMEDIATELY disconnect from the internet (this is typically the blue cable connected
to the back of your computer) to stop the ransomware from spreading.
o Begin the documentation process. Make sure evidence is being captured throughout.
Complete Incident Response Form (Section 11.0 Incident Response Form).
o Determine the scope of the ransomware infection. Is it on one computer, multiple
computers, or the entire network?
 Are the affected network segment(s) able to be shut down or disconnected?
o Categorize the incident based on severity. Responsibilities should be outlined for different
members of the organization at each level of incident severity.
 Who needs to be involved at each level?
 When does senior management and the Board get notified?
 When do we communicate with customers?
 What sort of status reports need to be kept and on what frequency?
o Determine the potential for the incident to escalate to a higher severity level.
 Will external parties (i.e. digital forensics or additional resources) be required?
o Notify appropriate law enforcement, third parties, or regulatory agencies.
o Ensure the process is being thoroughly documented.
o If possible, take a digital forensic image of the infected device(s).
o Investigate the strain of ransomware. There are mitigation tools out there that have
encryption keys for specific ransomware variants.
o If the key is not easily obtained, don’t bother trying to crack the ransomware encryption.
The ransomware will start destroying information long before the key can be cracked.
o Determine if it’s more appropriate to restore from backups (presuming they have not also
been encrypted) or to pay the ransom to obtain the key.
 This decision should depend on Recovery Time Objective (RTO) and Maximum
Allowable Downtime (MAD) measurables. If it will take seven (7) days to fully
restore business functionality, and you can’t afford to wait that long, paying the
ransom may be the most efficient path to restoration.
 The preferred policy practice is not to pay the ransom but a business
decision will be made on a case by case basis.
 Understand there are a lot of risks associated with paying the ransom.
The probability of repeat attacks will be increased, the institution will
have contributed to cyber-crime, and there is no guarantee that the key
will be provided by the attackers.
 If restoring from backups, be sure to scan backups for malicious code / malware
VERY THOROUGHLY. Many forms or ransomware employ delayed attacks, waiting
30-45 days before encrypting computers or files. This ensures that ransomware is
also on backups, and the ransomware will immediately re-deploy upon
restoration. Be very cautious.
o Watch the network for exfiltration of data. While most ransomware is simply an extortion
scam, some ransomware will exfiltrate data for sale or use at a later time.
o Ensure all workstations, servers, and devices are THOROUGHLY scanned (and rescanned) to

ensure they are free from infection before re-deploying anything back to a production
network.
o Consider a digital forensics investigation to determine the scope, depth, breadth, and
causes of the attack.
o Mitigate the exploited vulnerabilities for other hosts on the institution’s network.
o Analyze results of the digital forensic investigation (if applicable).
o Determine if any confidential customer information was accessed. Notify as necessary.
o Check with insurance agency to determine if any losses are covered.
determine necessary improvements to the Incident Response Plan.
o Share information with FS-ISAC or other industry intelligence sharing communities.
o Report to the FBI/IC3 (if not involved already).
o Plan for future ransomware incidents and test the plan periodically.
o Report to the Board of Directors.
6.6.3 Inappropriate Usage Incident
2. Acquire, preserve, secure, and document evidence.
o Fill out Incident Response Form (Section 11.0 Incident Response Form).
4. Contact Law Enforcement if applicable (See Section 6.6.4 Inappropriate Usage Matrix).
5. Contain and eradicate the incident.
o If applicable, contain and eradicate the incident, e.g., remove inappropriate materials; (See
Section 6.6.4 Inappropriate Usage Matrix).
6. Secure Sensitive Customer Information.
o Ensure the security of customer information (see Section 7.1 Evaluation).
7. Customer Notification.
o Utilizing the templated Incident Response Letters as a starting point, customize the letter
based upon the steps detailed in Section 7.2 Customer Notification and obtain appropriate
internal reviews prior to distribution.
8. Suspicious Activity Report.
o If applicable, file Suspicious Activity Report “SAR” (see Section 7.3 Suspicious Activity
Report).
10. Hold a Lessons Learned Meeting.
6.6.4 Inappropriate Usage Matrix
The following is a matrix to assist in identifying which external contacts to information depending on the
type of inappropriate usage; see Section 9.0 – Contact Information for the phone numbers. Contact
external agencies in the order listed below for they may provide additional guidance on contacting other
agencies.
Incident Action Evidence External Contact
General AUP Violation Warning n/a n/a
Resource Abuse Warning n/a n/a
Harassing Material Warning Remove n/a
Warning or
Pornographic Material Remove n/a
Termination
 County Law Enforcement
Child Pornography Termination Preserve
 FBI
 County Law Enforcement
Financial Crime (Embezzle-  Termination  FBI
Preserve
ment, Fraud, etc.)  SAR  FDIC
 Customer Notification
6.6.5 Unauthorized Access Incident
2. Perform an initial containment of the incident (e.g. disconnect internet service).
6. Confirm the containment of the incident.
o Further analyze the incident and determine if containment was sufficient (including
checking other systems for signs of intrusion).
o Implement additional containment measures if necessary.
o Identify and mitigate all vulnerabilities that were exploited.
o Remove components of the incident from systems.
o Return affected systems to an operationally ready state.
o Confirm that the affected systems are functioning normally.
o If necessary, implement additional monitoring to look for future related activity.
Report).
6.6.6 Denial of Service Incident (DoS)

o Verify there is an attack occurring.
o Determine the scope of the attack (what is being attacked?).
o Classify attack – is it based on sheer volume, or is it a low-and-slow approach? Is it
network-based (hitting your firewall) or application-based (hitting your website?).
o Ensure the attack is limited only to DDoS and does not involve other attacks (physical
security, social engineering, or other attempts to access information; DDoS can often be
used as a distraction for other attacks, or even for extortion).
o Acquire, preserve, secure, and document evidence.
3. Contain the incident – stop the DDoS if it has not already stopped.
o Identify and mitigate all vulnerabilities that were used.
o Network-based attack.
 Contact your ISP and change external IP addresses (network-based).
 Understand that there might be applications and external connections tied to that
external IP address; know in advance what will need to be changed and altered.
Considerations include direct connections to service providers (outsourced Core
Banking) and VPN access.
 Blacklist attack traffic if reasonable through IP or geolocation blacklisting.
 Contact a Content Delivery Network (CDN) if the attack is too large to mitigate
alone.
o Application-based attack.
 Contact your service provider if hosted elsewhere to determine the best course of
action.
 If hosted locally (via web-server in DMZ, for example), see Network-based attack
description above If not yet contained, contact the Internet Service Provider for
assistance in filtering the attack (see Section 9.0 Other Contact Information).
o If not yet contained, relocate the target.
o Ensure that all vulnerabilities utilized by the attack have been identified and mitigated.
 Note: Evidence of further vulnerabilities would be demonstrated by continued
DDoS Attacks.
o Ensure no other resources have been compromised.
o Return affected systems to an operationally ready state.
o Confirm that the affected systems are functioning normally.
o If necessary and feasible, implement additional monitoring to look for future related
activity.
o If customer-facing applications have been affected, determine if a notification is necessary.
determine improvements.
o Plan for next time and test the plan periodically.
6.6.7 Multiple Component Incidents

1. Report all incidents to the Incident Response Coordinator (IRC).

2. Prioritize handling the incident based on its business impact.
o Determine which incidents are criminal in nature.
o Forecast how severe the Banks reputation will be damaged.
o Determine the proper course of action for each incident component.
3. Follow the incident response procedures for each component in order of criticality, based on the
results of Step 2.
6.7 Handling Service Provider Incidents
Select the service provider which has reported an unauthorized access incident to the Organization and then
follow the associated procedures.
6.7.1 The Bankers Bank (IWEB)
Bankers Bank is an Internet-based electronic funds transfer system that provides My Company access to
the Federal Reserve for ACH and Wire Transfer services. This system communicates through a hardware-
based VPN device and validates itself using usernames and USB token based certificates. The procedures
in this section will outline steps the Bank can take if a security compromise in Bankers Bank is suspected.
A compromise consists of any unauthorized person suspected or obtaining and/or utilizing a private key
password protecting the private key, token-based certificate or confidential security documentation.
Unauthorized Access Incident
2. Perform an initial containment of the incident.
o Power down and disconnect the Bankers Bank VPN device.
5. Certificate Revocation.
o Request to revoke all certificates suspected of being compromised from the Registration
Authority.
o Further analyze the incident and determine if containment was sufficient (including
checking other systems for signs of intrusion).
o Remove components of the incident from systems.
o Delete and destroy all copies of the revoked certificates and/or tokens.

o Reconnect and power on the Bankers Bank VPN device.

o Confirm that the systems are functioning normally.
Report).
6.7.2 Fiserv EFT
My Company offers its customers a Debit/Credit Card service to perform transactions such as POS
purchases, ATM withdraws, and transferring of funds between accounts via an ATM. This section will
identify response procedures to follow when notified by Fiserv EFT of unauthorized access to the
Organization’s Debit Card information. This procedure will assume Fiserv EFT has positively identified the
discloser of sensitive customer information.
2. Complete Incident Response Form.
3. Notify Incident Response Team (see Section 8.0 Incident Response Team Contact Information)
4. Notify Debit Card personnel.
5. Contact the FDIC, (see Section 9.0 Other Contact Information). They will most likely have additional
requirements of the Organization; complete those requirements before proceeding with any
procedure.
6. Order New Cards.
o New debit cards need to be ordered from Fiserv EFT for all affected customers with active
accounts. Non-active accounts should not receive new cards; they should remain non-
active and receive a notification letter.
7. Cancel Compromised Cards.
o All cards that have had fraud occur, or those suspected of fraud, will be disabled
immediately using Fiserv EFT Website.
8. Notify customers; (see Section 7.2 Customer Notification).
Report).

6.7.3 <ATM Provider> - ATM Fraud
My Company offers ATMs to its customers. This section will identify response procedures to follow in the
event malicious activity was to occur on the ATM.
Skimming
2. Contact law enforcement.
 Do not draw attention to or remove device until law enforcement has been alerted.
Criminals routinely come back for skimming devices.
 Contact local law enforcement (see Section 9.1 Government Agencies)
 Contact FBI (see Section 9.1 Government Agencies)
 Contact FDIC (see Section 9.1 Government Agencies)
3. Contain the incident – disable device if possible.
4. Prioritize handling the incident based on the business impact.
 Estimate the current and potential effect of the incident.
 Utilize forensic specialist to determine which customers were affected, (see Section 9.0
Other Contact Information).
5. Suspicious Activity Report
 If applicable, file Suspicious Activity Report “SAR” (see Section 7.3 Suspicious Activity
Report).
 Fill out Incident Response Form (see Section 11.0 Incident Response Form).
 Continue maintaining the Chronological Log of Events.
 Fill out Incident Response Form.
 Report to the Board of Directors regularly.
Unlimited Operations
2. Contain the incident – disable devices if possible.
 Contact <ATM Provider> to disable devices.
 Contact <ATM Processor> to halt processing of additional transactions.
 Estimate the current and potential effect of the incident.
4. Contact law enforcement.
 Contact local law enforcement (see Section 9.1 Government Agencies)
 Contact FBI (see Section 9.1 Government Agencies)
 Contact FDIC (see Section 9.1 Government Agencies)
 If applicable, file Suspicious Activity Report “SAR” (see Section 7.3 Suspicious Activity
Report).
 Fill out Incident Response Form (see Section 11.0 Incident Response Form).
 Continue maintaining the Chronological Log of Events.
 Fill out Incident Response Form.
 Report to the Board of Directors regularly.
6.7.4 Fiserv Internet Banking

My Company operates an online Internet Banking system which allows individual customers to access
their accounts, transfer funds between common account holders, view checks and statements, and make
remote deposits. This section will identify response procedures to follow when notified by Fiserv Internet
Banking of unauthorized access to the Organization’s customer information. This procedure will assume
Fiserv Internet Banking has positively identified the discloser of sensitive customer information.
Unauthorized Access Incident.
1. Report the incident to the Incident Response Coordinator (IRC) / Information Security Officer.
2. Identify the Incident.
o The first thing to determine: is Fiserv Internet Banking certain that the compromise or
attack has been contained?
o If there is no certainty that the attack has been contained, the decision will have to be
made to either:
 Shut down all Fiserv Internet Banking products until the attack can be confirmed
to be over.
 Move online banking from real-time into batch mode.
o If the attack is determined to be over, online banking will not be shut down.
3. Contain the Incident.
o Notify the Chief Executive Officer, who will, in turn, notify insurance, attorneys, law
enforcement, and the Executive Team.
 Chief Executive Officer should work with the legal team to determine if a
customer notification communication should be sent out prior to the certainty of
the bank’s data being compromised.
o Establish a key contact with the vendor and maintain frequent and ongoing
communications (set expectations with the vendor to keep communications open).
o Notify internal employees to the potential breach and ask them to keep an eye out for
fraudulent transactions and activity.
o Contact card fraud services provider Fiserv Internet Banking and lower the risk tolerance to
catch any suspicious activity.
4. Eradicate the Incident.
o Remove compromised components of the incident from systems.
5. Recover from the Incident.
o If a determination is made that customer accounts have been compromised, a decision to
notify customers will be made and applicable security changes to internet banking applied.
 Mass-reset customer internet banking passwords or force two-factor
authentication upon next login.
 Increase fraud and risk monitoring of accounts.
 Communicate the compromise to customers upon legal approval.

Report).
6. Document the Incident.
6.7.5 Cloud-based Software-as-a-Service providers

My Company utilizes a number of applications and programs that operate completely via the internet
through a web browser (no locally installed software). These cloud-based software-as-a-service (SaaS)
applications include: UBB/UNET, Margin Maximizer/ProfitStars Financial Performance Suite/Jack Henry,
Web Equity, Shazam, Deluxe, and Funds Express/FDR (Electronic Banking).
This section will identify response procedures to follow when notified by any of the above SaaS of
unauthorized access to the Organization’s customer information. This procedure will assume the SaaS
provider has positively identified the discloser of sensitive customer information.
3. Notify Incident Response Team (see Section 8.0 Incident Response Team Contact Information).
4. Notify Internet Banking personnel.
procedure.
6. Reset Passwords.
o All accounts suspected of unauthorized access must have passwords reset on the
Management Console Admin Platform Website.
Report).
6.7.6 Corporate Account Takeover (CATO)
Corporate Account Takeover (CATO) procedures should be followed if a financial loss occurs and appears
to be isolated to one customer.
1. Ensure strong controls are in place at the institution to prevent fraudulent transactions (dual
controls, transaction verification, etc.).

2. Identify the Incident.
o Report the incident to the Information Response Coordinator (IRC).
o Notify the Business Banking Department.
o Most fraud will be to payees to which the customer has never sent funds or to foreign
countries. Ensure proper procedures are followed.
o Abnormal activity should be suspected.
o If fraud is suspected; determine where the process is currently in the transaction lifecycle.
Did the wire JUST get sent? Can it be recovered?
o Determine the number of funds being transferred fraudulently.
o Determine if the fraud is an internal bank issue (attackers have access to internal
institution funds-transfer systems) or an external customer issue.
 If internal, shut down all payment transactions at once and contact any affected
customers.
 Do not unplug computers or servers from the power source, but disconnect from
the internet. This is typically achieved by disconnecting the blue cable from the
back of the machine.
 If a network breach is suspected, contact a digital forensic investigator to
determine the scope, depth, breadth, and causes of the breach.
o Determine what was accessed. If confidential customer information has been accessed and
exfiltrated, customers will need to be contacted.
o If external fraud has already occurred and there is no chance of recovery, contact the FBI.
There might be some hope of recovering funds before they leave the country.
 If unrecoverable, the institution has two (2) options based upon the facts and
details of the incident. Legal advice may be sought before making a final decision.
 Reimburse the customer.
 Do not reimburse the customer.
o Estimate the current and potential effect of the incident.
o Identify a single point of contact with the customer to minimize reputational damage and
the institution’s liability for loss.
5. Recovery and Response:
o Determine whether customers need to be notified.
o Contact insurance provider to determine if any funds qualify for reimbursement.
o If internal fraud, ensure a digital forensic investigation is performed.
determine improvements.
o Plan for next time and test the plan periodically.
6.7.7 Managed Technology Service Providers
My Company utilizes a select few third parties to help manage and monitor the institution’s internal
network. These managed technology service providers include: Modern Banking System (MBS) – Network,
Domain, Core System.
This section will identify response procedures to follow when notified by any of the above MTS providers
of unauthorized access to either the third party’s network or to the institution’s network via the third
party. This procedure will assume the vendor has positively identified the source of the incident and is
actively working to resolve the issue.

3. Notify Incident Response Team (see Section 8.0 Incident Response Team Contact Information).
4. Notify Internet Banking personnel.
procedure.
6. Reset Passwords.
o All accounts suspected of unauthorized access must have passwords reset on the
Management Console Admin Platform Website.
Report).
o Report to the Board of Directors.
6.8 Handling Physical Theft or Loss Incidents

Physical theft or loss of Organization property does not only result in monetary losses, but it could also result
in unauthorized access to sensitive Organization and/or customer information. The following procedures will
assist the Organization in assessing, documenting, and notifying the appropriate people.
6.8.1 Unauthorized Access Incident
2. Perform an initial containment of the incident (e.g. action to prevent further losses).
o Ensure the security of customer information by investigating the possible contents of the
missing item. If the Organization has reason to believe that unsecured customer
information was contained on the missing item, the Organization must assume that the
security of the customer information has been compromised. If customer information was
secured, those controls should be evaluated to determine if they are sufficient to prevent
unauthorized access (see Section 7.1 Evaluation).
6. Police Report.
o If applicable, contact local law enforcement and file a police report Contact local law
enforcement and file a police report for specific items stolen or perceived to be stolen (see
Section 9.0 Other Contact Information).

o Further analyze the incident and determine if containment was sufficient (e.g. check
inventories for other missing items).
o Resume normal business operations.
o Remove missing items from inventories, carefully document this process.
Report).
7.0 Customer Information Definition

Information in this section will be used to define sensitive customer information and provide guidance if the
security of this information is compromised.
Sensitive customer information is defined by the Gramm-Leach-Bliley Act (GLBA) as: sensitive customer
information means a customer’s name, address or telephone number in conjunction with the customer’s
Social Security number, driver’s license number, account number, credit or debit card number, or a personal
identification number or password that would permit access to the customer’s account. It also includes any
combination of components of customer information that would allow someone to log on to or access the
customer’s account, such as user name and password or password and account number.
7.1 Evaluation
Complete the following procedure to evaluate the incident:
1. Evaluate the incident to determine if unauthorized access to or use of sensitive customer
information has occurred.
1. NO – The security of customer information has not been breached, resume previous
incident response procedure. However, if the Organization becomes aware a breach in
customer information security at a later time, it must resume this procedure.
2. YES – Continue with this procedure.
2. Notify Incident Response Team and Board of Directors.
4. Contact the FDIC, (see Section 9.1 Government Agencies). They will most likely have additional
procedure. For assistance in contacting the regulators by email, please reference the
Communication to Regulators Letter. This letter can also be used as a guide when calling incidents
into the regulators.
5. Return to previous incident response procedure and complete the remaining steps. After
completing those procedures resume this procedure.
6. Notify customers; (see Section 7.2 – Customer Notification).
7. Complete the Suspicious Activities Report (SAR), (see Section 7.3 Suspicious Activity Report).
7.2 Customer Notification
If the Organization determines that misuse or unauthorized access to customer information has occurred or is
reasonably possible, customers should be notified of the incident involving their information immediately
following the resolution of the incident. This notification can be limited to those customers which the
Organization can determine are affected by the incident. However, if the Organization cannot determine
which customers are affected, all customers shall be notified. Notification can be delayed if requested by a
government agency; this request must be given to the Organization in writing. Customer notification should
include the following:
1. General description of the incident.
2. Type of customer information that was misused or subject to unauthorized access.
3. Steps taken to protect customers’ information from this incident.
4. Contact and telephone number for further information and assistance.
5. Remind the customer they need to remain alert for at least 12 to 24 months for indications of
possible identity theft and suspicious activity. They must immediately report any such activities to
the Organization.
6. Recommend the customer to review account statements and immediately report suspicious activity
to the Organization.
7. Inform customers about fraud alerts and advise them to place them on their credit reports.
8. Recommend the customer review credit reports; these can be obtained for free.
9. Provide additional guidance, such as www.ftc.gov/IDTheft.
Customer notifications must be delivered in a manner that the customer can reasonably expect to receive it.
Generally, customer notifications are delivered by mail, but it is also acceptable to individually phone each
customer. Customers could also be notified by email if the customer has given consent to receive
communications electronically. The Organization may also wish to include along with their notification letter a
copy of the Reference Contacts document.
The FDIC also encourages financial institutions to notify the nationwide consumer reporting agencies prior to
sending notices to a large number of customers that include contact information for the reporting agencies;
(see Section 9.1 Government Agencies).
Once customers receive their notification letter, the Organization will more than likely receive multiple phone
calls. It is important that the Organization inform their employees of the situation and provide them enough
information to answer customer’s questions. In order to ensure employees know how to respond to customer
questions, scripted talking points will be created. This will be distributed to all employees prior to customer
notification letters being mailed. Additionally, an employee meeting may be held to discuss the incident and
talking points.
7.3 Suspicious Activity Report
Suspicious Activity Report (“SAR”) regulations require the Organization to file a report whenever a computer
intrusion occurs. SAR regulations define computer intrusions as “gaining access to a computer system of a
financial institution to:
1. Remove, steal, procure or otherwise affect funds of the institution or the institution’s customers;
2. Remove, steal, procure or otherwise affect critical information of the institution including customer
account information: or
3. Damage, disable or otherwise affect critical systems of the institution.”
SAR regulations also require the Organization to file a report whenever there is insider abuse of any amount.
Reports must be filed within 30 days if a suspect has been identified and within 60 days if a suspect has not
been identified. For more information about the requirements of SAR and information about filing the report,
please see the Suspicious Activity Report.
8.0 Incident Response Team Contact Information
8.1.1 Incident Response Coordinator

Organization Contact Name Phone Numbers
My Company ISO (405) 834-6551
8.1.2 Incident Response Team
My Company (555) 555-5555
My Company (555) 555-5555
My Company (555) 555-5555
My Company (555) 555-5555
My Company (555) 555-5555
My Company (555) 555-5555
8.1.3 Extended Team
Law Firm (555) 555-5555
Insurance (555) 555-5555
8.1.4 External Support Contacts
Organization Name Phone Numbers
SBS Cybersecurity, LLC Support Team 605-923-8722
Tech Support Team (555) 555-5555
9.0 Other Contact Information

9.1 Government Agencies
County Law Enforcement (Oklahoma County Sheriff).............................................................(405) 713-1000
Oklahoma State Banking Dept.................................................................................................(405) 521-2782
Federal Bureau of Investigation (FBI – Oklahoma, OK)............................................................(405) 290-7770
Federal Deposit Insurance Corporation (FDIC – Regional: Kansas City)...................................(800) 209-7459
U.S. Federal Trade Commission...............................................................................................(877) 438-4338
9.2 Technical
Technology..............................................................................................................................(555) 555-5555
SBS Cybersecurity, LLC.............................................................................................................(605) 923-8722
9.3 Debit Cards
Fiserv EFT..................................................................................................................................(800)888-0085
9.4 Internet Banking
Fiserv Ecorp/Retail...................................................................................................................(800) 376-4019
9.5 Nationwide Consumer Reporting Agencies

Equifax.....................................................................................................................................(800) 525-6285
Experian...................................................................................................................................(800) 397-3742
TransUnion..............................................................................................................................(800) 680-7289
9.6 Major Correspondent Banks
United Bankers Bank...............................................................................................................(800) 558-6878
Federal Reserve Bank (Minneapolis, MN)................................................................................(888) 333-7010
9.7 Detailed Contact Information

The Bankers Bank.....................................................................................................................(405)848-8877
10.0 Potential Breach Response Vendors
Breach Coach...........................................................................................................................(555) 555-5555

Legal Services...........................................................................................................................(555) 555-5555
Forensics..................................................................................................................................(555) 555-5555
Payment Card Industry (PCI) Forensics....................................................................................(555) 555-5555
Notification..............................................................................................................................(555) 555-5555

11.0 Incident Response Form
General Information Date of incident:
Employee Name: Department / Location:
Contact Information: Has the Information Security

Officer been notified? Yes No
Incident Details
Type of Incident: Malicious Code Inappropriate Usage
Unauthorized Access Denial of Service
Physical Theft or Loss Other (provide additional information)
Service Provider Incident
Additional Information:
System(s) Involved: Workstations / MS Windows E-mail

Network / Firewall Website
Core Banking System Paper-based
Electronic Banking Other (provide description)
Description:
Type of information involved:
Has the Incident Response Team been Has the Board of Directors been
Yes No Yes No
notified? notified?
Others Contacted Law Enforcement (please specify)

Regulators (please specify)
Service Providers (please specify)
Correspondent Banks (please specify)
Insurance (please specify)
Other (please specify)
Prior occurrence(s) of incident? Yes No Unknown
If yes, please provide date and description:

Customer Information
Was Sensitive Customer Information If yes, has misuse of the information occurred or is it
Yes No Yes No
involved? reasonably possible that misuse will occur?
If yes, by what means will

Is Customer Notice Required? Yes No Letter E-mail Phone
customers be notified?
List affected customers:
Resolution
Corrective actions taken:
Highest Escalation Level? 1 2 3 Is further action required? Yes No
Outcome / Resolution:
Estimated monetary loss?
Was the Incident Response Plan Followed? Yes No If not, why?
Recommended changes to Incident Response Plan:
Recommended changes to
policies / procedures:
Other Notes:
Approval
IR Team Leader: Date:
Information Security Officer: Date:

12.0 Sample Customer Notification Letter
<Date>
<Organization Address>
Dear Cardholder:
It has recently been brought to our attention that there has been a possible compromise that involves
unauthorized access to cardholder account information.
MasterCard® has detected a security breach of a merchant database which contained your debit card
information. We have not been informed of the merchant location in which this compromise took place.
The result is a potential risk of fraudulent debit card activity on your account.
In order to mitigate this risk, we will be canceling your current debit card and issuing a new card.
The following are some steps that you may wish to take to protect yourself and your accounts against
future fraudulent attempts:
- Never provide personal account information to anyone contacting you by telephone, e-mail, or
through a text message.
- Carefully examine all billing statements to verify and confirm the charges listed. If anything looks
suspicious, promptly report the incident to us or to the financial institution that issued the card.
- The Federal Trade Commission (FTC) has a Web site dedicated to identity theft. It is
www.consumer.gov/idtheft. You may also call the FTC at (877)382-4357 to obtain identity theft
guidance or to report suspected incidents of identity theft.
- It is important to obtain free yearly copies of your credit reports. Each consumer is entitled to one free
report from each of the credit reporting agencies. To easily get your free copies, you may either access
the Web site at www.annualcreditreport.com or call (877) 322-8228.
- Contact information for the three major credit bureaus is: Equifax; PO Box 740241; Atlanta, GA 30374;
1-800-685-1111: Experian; PO Box 2002; Allen, TX 5013; 1-888-397-3742: TransUnion; PO Box 1000;
Chester, PA 19022; 1-800-888-4213.
While My Company’s records were not compromised, we take our obligation seriously of informing you
of any potential risk to your account. Please be assured that My Company is committed to the security
of your personal information and has the highest security standards in place.

Sincerely,
<Contact>


Incident Response Plan

Uploaded by

Copyright:

Available Formats

Incident Response Plan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Incident Response Plan

Uploaded by

Copyright:

Available Formats

1.

Incident Response Plan

6.6 Procedures for Handling Specific Information Technology Incidents..........................................14

9.7 Detailed Contact Information........................................................................................................30

Incident Response Plan

Internal Information 5 Powered by TRAC™

Incident Response Team Contact Information in section 8.0

5.0 Incident Response Preparation

Internal Information 6 Powered by TRAC™

• Director/Senior Management cybersecurity training.

customers using these services.

6.3 Threat Intelligence Program

Firewall Alerts https://perimeter.securityview.com Internal

SBS Cybersecurity Blog https://sbscyber.com/ External

KnowBe4 Blog https://blog.knowbe4.com External

Internal Information 8 Powered by TRAC™

6.4 Information Technology Incident Identification Matrix

Severity Level Description

Internal Information 9 Powered by TRAC™

6.4.2 Incident Identification Matrix

Threat Score Potential Af-

Internal Information 10 Powered by TRAC™

6.5 Escalation Procedures

6.5.1 Escalation Level 1 - Minimal Escalation

o Determine initial defensive action required.

6.5.4 Escalation Level 4 - High Escalation.

Internal Information 12 Powered by TRAC™

 Incident Response Coordinator.

3. Status Report / Communication Report.

 Senior Management / Board of Directors.

6.6 Procedures for Handling Specific Information Technology Incidents

2. Identify the incident.

6. Document the incident.

Internal Information 15 Powered by TRAC™

6.6.6 Denial of Service Incident (DoS)

Internal Information 18 Powered by TRAC™

1. Report all incidents to the Incident Response Coordinator (IRC).

Internal Information 19 Powered by TRAC™

o Reconnect and power on the Bankers Bank VPN device.

o Fill out Incident Response Form.

6.7.4 Fiserv Internet Banking

 Communicate the compromise to customers upon legal approval.

6.7.5 Cloud-based Software-as-a-Service providers

controls, transaction verification, etc.).

actively working to resolve the issue.

6.8 Handling Physical Theft or Loss Incidents

Section 9.0 Other Contact Information).

7.0 Customer Information Definition

8.1.1 Incident Response Coordinator

9.0 Other Contact Information

9.5 Nationwide Consumer Reporting Agencies

9.7 Detailed Contact Information

Breach Coach...........................................................................................................................(555) 555-5555

Internal Information 29 Powered by TRAC™

11.0 Incident Response Form

General Information Date of incident:

Employee Name: Department / Location:

Contact Information: Has the Information Security

System(s) Involved: Workstations / MS Windows E-mail

Type of information involved: