Incident Response Plan

INCIDENT RESPONSE PLAN

INTRODUCTION

An Incident Response Plan (“IRP”) is a structured and documented approach that an organization follows to effectively respond to and manage security incidents, such as cyberattacks, data breaches, system compromises, or any other events that threaten the confidentiality, integrity, or availability of data, systems, or resources. Incidents such as these can have significant financial, operational, and reputational consequences. An IRP helps an organization minimize damage by providing a structured and organized approach to responding to incidents promptly. It outlines the steps to contain, mitigate, and recover from a security incident effectively and efficiently.

The Kredit Financial Inc. (“Kredit”) IRP covers the following phases:

1. Detection

2. Containment

3. Analysis

4. Eradication & Prevention

5. Recovery

6. Post-Incident Activities

Definitions:

• A Security Event and a Security Incident are two related but distinct concepts in the field of information security. The key difference between a Security Event and a Security Incident is that a Security Event is a broader term that encompasses all observable occurrences within a system or network, while a Security Incident specifically refers to those events that are detrimental to the security of an organization and often require a response to mitigate the impact and investigate the cause. It's important to distinguish between ordinary Security Events and potentially harmful Security Incidents to prioritize responses and allocate resources effectively.

  • A Security Event (“Event”) is any observable occurrence in a computer system or network that has the potential to impact the confidentiality, integrity, or availability of data or resources.

  • A Security Incident (“Incident”) is a specific type of security event that has been confirmed to be a violation of an organization's security policies, procedures, or acceptable use policies. Incidents are events that pose a threat to the confidentiality, integrity, or availability of data or systems.

• A Data Breach is a Security Incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, PII or Personal Data.

• An Incident Record is a record created at the time a Security Incident is initially recognized. Contains all relevant information pertaining to the Security Incident.

• Incident Response is the process for detecting, reporting, assessing, responding to, dealing with, and learning from Security Incidents.

• Information Security is the preservation of confidentiality, integrity, and availability of Information and the equipment, devices or services containing or providing such information.

• Personally Identifiable Information (PII) or Sensitive Information (see Kredit’s Data Classification and Handling Policy for additional info) is any data or information that can be used to identify an individual or be linked to a specific person. PII is often sensitive in nature and, if mishandled or exposed, can lead to privacy breaches and identity theft. It includes various pieces of information that, when combined, can uniquely identify an individual. Examples of PII may include:

  • Full Name: A person's first and last name or any combination of their legal names.

  • Home Address: Information about where an individual lives, including street address, city, state, and postal code.

  • Phone Number: Contact information, such as a mobile or landline phone number.

  • Email Address: A person's email address, which is often used for communication and account verification.

• The Security Incident Response Team (“SIRT”) is the predefined group of individuals at Kredit that are responsible for responding to a security incident.

• A Security Vulnerability is a weakness of an existing asset or control that can be exploited by one or more threats.

• A Security Weakness is a weakness that results from the lack of existing, necessary controls.

PURPOSE

The purpose of this IRP is to define the steps that must be followed by Kredit in the event of an Incident.

POLICY

The purpose of this IRP is to define the steps that must be followed by Kredit in the event of an Incident.

SCOPE

This IRP is applicable to any information system used to store, process, transmit, or access Kredit and its client data, as well as all employees and contractors (together referred to as “employees”) who are authorized to access Kredit assets and information resources.

PROCEDURE

Kredit employees are required to follow the procedures to ensure:

• All Incidents are detected, analyzed, contained, and eradicated.

• Measures are taken to prevent any further Incidents.

• Where necessary or appropriate, notice is provided to law enforcement authorities, clients, and/or affected parties.

Security Incident Response Team & Responsibilities

The following individuals are responsible for responding to an Incident and make up the Security Incident Response Team (SIRT). The SIRT members include the following:

• Chief Technology Officer (Primary Lead)

• Principal Software Engineer (Secondary Lead)

• Chief Compliance Officer

• Chief Executive Officer

SIRT Roles and Responsibilities

SIRT Member Role	SIRT Member Role
Chief Technology Officer	Serve as primary lead on the SIRT. Coordinate the SIRT when notified of an Incident. Lead Incident review. Provide regular updates and reports to senior management and executives regarding the organization's security posture, any ongoing incidents, and the effectiveness of the Incident Response Plan.
Information Security Officer	Serve as secondary lead on the SIRT. Contain Incidents to mitigate the associated impact. Determine whether an Event is an actual Incident. Remove identified vulnerabilities from the impacted environment(s). Restore affected systems to operation. Ensure digital evidence is preserved in a forensically sound manner.
Chief Compliance Officer	Work with the ISO and CTO to develop and maintain the organization's Incident Response Plan. Ensure that the incident response process complies with relevant laws, regulations, and contractual obligations. Ensure the organization has the most current set of notification and timeline requirements at the federal and state level. Notify appropriate authorities. Work with CEO and external counsel to develop appropriate messaging to consumers, clients, and state authorities. Develop and administer training related to the Incident Response Plan and each employee’s role and responsibility.
Chief Executive Officer	Provide client-level Incident notifications in accordance with contractual requirements. Notification to clients and media of an Incident.

Detection Phase

In the Detection Phase, the SIRT identifies an Event that may be the result of a potential exploitation of a Security Vulnerability or a Security Weakness, or that may be the result of an innocent error. Immediately upon observation or notice of any suspected Event, employees shall use reasonable efforts to promptly report such knowledge and/or suspicion to the SIRT at the following address: [e-mail].

An Event may be discovered in many ways, including, but not limited to the following:

• Observation of suspicious behavior or unusual occurrences on information systems.

• Lapses in physical or information security.

• Sensitive information that comes into the possession of unauthorized employees or third parties.

• Sensitive information inappropriately exposed on a publicly facing website.

To assess whether an Event must be reported, employees shall consider whether there are indications that:

• Sensitive information was used by unauthorized employees or third parties.

• Sensitive information has been downloaded or copied inappropriately from Kredit’s computer systems or equipment.

• Equipment or devices containing Information have been lost or stolen.

• Equipment or devices containing Information have been subject to unauthorized activity (e.g., hacking, malware).

• Sensitive information has been inappropriately disclosed, accessed, or transferred.

In addition, the following situations shall be considered for Event reporting:

• Ineffective security controls

• Breach of information integrity, confidentiality, or availability expectations

• Human errors (intentional or otherwise)

• Non–compliance with policies or standards

• Breaches of physical security arrangements

• Uncontrolled systems changes

• Malfunctions of software or hardware

• Access violations

Even if employees are not sure whether an Event is an actual Incident, they are still required to report it as provided herein, as it is better to be cautious than to be compromised.

The SIRT may require the employee reporting the Event to supply further information, which will depend upon the nature of the event itself. However, the following information must be supplied at minimum:

• Contact name and information of person reporting the Event.

• Date and time the Event occurred or was noticed.

• Type and circumstances of the Event.

• The type of data, information, or equipment involved.

• Location of the Event, data, or equipment affected.

• Whether the Event puts any person or other data at risk.

The SIRT Primary Lead, or the SIRT Secondary Lead if the Primary Lead is unavailable, will ensure that the SIRT is promptly engaged once such notice is received. The following actions will also be taken:

• The SIRT, under the leadership of the SIRT Primary Lead, shall use reasonable efforts to analyze the matter within twelve (12) hours of notice and decide whether to proceed with the Analysis Phase.

  • Determination to initiate the Analysis Phase must be made quickly so that employees can make an initial determination as to the urgency and seriousness of the situation.

• Upon making the decision to begin the Analysis Phase, if the SIRT suspects that the Event may result in damage to the reputation of Kredit or legal liability, legal counsel shall be sought.

Containment Phase

The Containment Phase mitigates the root cause of the Incident to prevent further damage or exposure. This phase attempts to limit the impact of an Incident prior to an eradication and recovery event. During this phase, the SIRT may implement controls, as necessary, to limit the damage from an Incident. If an Incident is determined to be caused by innocent error, the eradication phase may not be needed. For example, after reviewing any information that has been collected investigating the Incident the SIRT may:

• Secure the physical and network perimeter.

  • (i)For example, shutting down a system, disconnecting it from the network, and/or disabling certain functions or services.

• Connect through a trusted connection and retrieve any volatile data from the affected system.

• Determine the relative integrity and the appropriateness of backing the system up.

• If appropriate, back up the impacted system.

• Change the password(s) to the affected system(s). Employees, as appropriate, shall be notified of the password change.

• Determine whether it is safe to continue operations with the affected system(s).

  • (i) If it is safe, allow the system to continue to function, in which case the SIRT will:

    • (a) Update the Incident Record; accordingly, and

    • (b) Move to the Recovery Phase.

  • (ii) If it is not safe to allow the system to continue operations, the SIRT will discontinue the system(s) operation and move to Eradication Phase.

  • (iii) The SIRT may permit continued operation of the system under close supervision and monitoring if:

    • (a) Such activity will assist in identifying individuals responsible for the Incident.

    • (b) The system can run normally without risk of disruption, compromise of data, or serious damage.

    • (c) Consensus has been reached within the SIRT before taking the supervision and monitoring approach.

• The final status of this stage shall be appropriately documented in the Incident Record.

• The SIRT shall apprise senior management of the progress, as appropriate.

During the Analysis and Containment Phases, the SIRT shall keep notes and use appropriate chain of custody procedures to ensure that the evidence gathered during the Incident can be used successfully during prosecution, if appropriate.

Analysis Phase

The initial response to detection of an Event is typically the Analysis Phase. In this phase the SIRT determines whether an Event is an actual Incident. To determine if an Event is an Incident, the following considerations apply:

• Leverage diagnostic data to analyze the Event using tools directly on the operating system or application. This may include, but not be limited to:

  • Taking screenshots, memory dumps, and network traces.

  • Performing analysis on the information being collected.

  • Analyzing the precursors and indications.

  • Looking for correlating information.

  • Performing research (e.g., search engines, knowledgebase).

• Identify whether the Event was the result of an innocent error or the actions of a potential attacker. If the latter, effort shall be made to identify who the potential attacker may be, by processes such as:

  • Validating the attacker’s IP address

  • Researching the attacker through search engines

  • Using incident databases

  • Monitoring attacker communication channels (if possible)

  • Potentially scanning the attacker’s system

If the SIRT has determined that an Event has triggered an Incident, the appropriate SIRT team members will be engaged accordingly and the SIRT will begin documenting the investigation and gathering evidence. The type of Incident is based on the nature of the event. Example types are listed as follows:

• Data exposure

• Unauthorized access/Inappropriate role-based access

• Distributed Denial of Service/ Denial of Service (“DDoS/DoS”)

• Malicious code

• Improper usage

• Scans/Probes/Attempted access

If it is determined that an Incident has not been triggered, additional activities noted under Post-Incident Activities may be initiated under the direction of the SIRT.

The Incident’s potential impact on Kredit shall be evaluated and the SIRT shall assign an initial severity classification of low, medium, high, or critical to the Incident. To analyze the situation, scope, and impact, the SIRT shall:

• Define and confirm the severity level and potential impact of the Incident.

• Identify which resources have been affected and forecast which resources will be affected.

• Estimate the current and potential effect of the Incident.

The SIRT shall attempt to determine the scope of the Incident and verify if the Incident is still ongoing. Scoping the Incident may include collecting forensic data from suspect systems or gathering evidence that will support the investigation. It may also include identifying any potential data theft or destruction. New investigative leads may be generated as the collected data is analyzed. If the Incident involves malware, the SIRT shall analyze the malware to determine its capabilities and potential impact to the environment. Based on the evidence reviewed, the SIRT will determine if the Incident requires reclassification as to its severity or cause (e.g., whether it was originally thought to be the action of a malicious actor but turned out to be an innocent error, or vice versa).

As indicated above, an Incident may require evidence to be collected. The collection of such evidence shall be done with due diligence and the following procedures shall apply:

• Gathering and handling of evidence (forensics) shall include:

  • Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) address, and IP address of a computer)

  • Name, title, and phone number of everyone who collected or handled the evidence during the investigation.

  • Time and date (including time zone) of each occurrence of evidence handling.

  • Locations where the evidence was stored, and conditions of storage (e.g., locked spaces, surveilled spaces)

  • Reasonable efforts to create two backups of the affected system(s) using new, unused media — one is to be sealed as evidence and one is to be used as a source of additional backups.

• To ensure that evidence is not destroyed or removed, where any employees are suspected of being responsible for an Incident, Kredit shall use reasonable efforts to place monitoring and/or confiscate all computer/electronic assets that have been assigned to the individual.

  • This task may be done surreptitiously and shall be completed as quickly and in as non-intrusive a manner as possible.

  • The SIRT shall consider restricting access to the computers and attached peripherals (including remote access via VPN, secure remote system access, etc.) pending the outcome of its examination.

• Where applicable, and depending upon the seriousness of the Incident, items and areas that shall be secured and preserved in an “as was” condition include:

  • Computer hardware (keyboard, mouse, monitor, CPU, etc.)

  • Software

  • Storage media (disks, tapes, removable disk drives, CD ROMs, etc.)

  • Documentation (manuals, policies, notepads)

  • Additional components as deemed relevant (printer, cables, etc.)

  • In cases of damage, the computer system, and its surrounding area, as well as other data storage devices, shall be preserved for the potential collection of evidence (e.g., fingerprinting).

  • If the computer is “Off”, it shall not be turned “On.” For a stand-alone computer system, if the computer is “On,” the CTO should be contacted.

• It is important to establish who was using the computer system at the time of the Incident and/or who was in the immediate area. The SIRT shall obtain copies of applicable records as part of the investigation.

• Based on the severity level and the categorization of the Incident, the proper team or employees shall be notified and contacted by the SIRT.

• Until the SIRT, with the approval of Kredit’s CEO, makes the Incident known to other employees, the foregoing activities shall be kept confidential to the extent possible.

• If it is determined that an Incident has occurred and may have a significant impact on Kredit, the SIRT shall determine whether additional resources are required to investigate and respond to the Incident. The extent of the additional resources will vary depending on the nature and significance of the Incident.

Eradication & Prevention Phase

The Eradication Phase is the phase where vulnerabilities causing the Incident, and any associated compromises, are removed from the environment. An effective eradication for a targeted attack removes the attacker’s access to the environment all at once, during a coordinated containment and eradication event. Although the specific actions taken during the Eradication Phase can vary depending on the Incident, the standard process for the Eradication Phase shall be as follows:

• Determine the symptoms and cause related to the affected system(s).

• Eliminate components of the Incident. This may include deleting malware, disabling breached user accounts, etc.

• Strengthen the controls surrounding the affected system(s), where possible (a risk assessment will be performed, if needed). This may include the following:

  • Strengthening network perimeter defenses o Improving monitoring capabilities or scope

  • Remediating any security issues within the affected system(s), such as removing unused services or implementing general host hardening techniques.

  • Conduct a vulnerability assessment to verify that all the holes/gaps that can be exploited have been addressed.

• If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.

• Update the Incident Record with the information learned from the vulnerability assessment, including the cause, symptoms, and method used to fix the problem with the affected system(s).

After Kredit has implemented the changes for eradication, it is important to verify that cause of and individual(s) causing the Incident is fully eradicated from the environment. The SIRT shall also test the effectiveness of any security controls or changes that were made to the environment during containment and eradication.

Recovery Phase

The Recovery Phase represents the SIRT’s effort to restore the affected system(s) to operation after the problems that gave rise to the Incident, and the consequences of the Incident, have been corrected. Recovery events can be complex depending on the Incident type and can require full project management plans to be effective.

Although the specific actions taken during the Recovery Phase can vary depending on the identified Incident, the standard process to accomplish this shall be as follows:

• Execution of the following actions, as appropriate:

  • Installing patches

  • Rebuilding systems

  • Changing passwords

  • Restoring systems from clean backups

  • Replacing affected files with clean versions

• Determination whether the affected system(s) has been changed in any way.

  • If the system(s) has been changed, the system is restored to its proper, intended functioning (“last known good”).

    • Once restored, the system functions are validated to verify that the system/process functions as intended. This may require the involvement of the business unit that owns the affected system(s).

    • If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline), it shall be restored and validated, and the system(s) shall be monitored for proper behavior.

  • If the system(s) has not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.

  • Implementation of additional monitoring and alerting may be done to identify similar activities.

  • Update the Incident Record with any details determined to be relevant during this phase.

Post-Incident Activities

In addition to the Data Breach notification requirements identified in the analysis phase above, and after verification of a successful containment and any necessary eradication, the SIRT shall take the following post-incident activities, as may be necessary:

Notification

U.S. data breach notification laws vary across all 50 states and U.S. territories. Each law must be applied to every factual scenario to determine when and if notification is required. Notification may include the state’s impacted residents and/or the state’s attorney general, depending on the number of residents that are affected. The timing of the notification ranges from, “as expeditiously as possible and without unreasonable delay” to up to ninety (90) days, depending on the state. See the US State Data Breach Notification Chart for specific state details.

The SIRT shall provide notice and disclosure to Kredit employees and clients within twenty-four (24) hours of identification. Where appropriate, the SIRT may:

• Prepare a general notice and arrange for providing the notice to employees and/or affected parties.

• Prepare a FAQ based on the notice and arrange to have it posted to the Kredit website after the notice has been sent.

• Identify a point a contact for employees and/or affected parties to contact if further information is sought.

• Establish a toll-free number for use by stakeholders.

Kredit’s objective is to provide notice in a manner designed to ensure that employees and/or affected parties can reasonably be expected to receive the disclosure. The form and content of the of notification may either be by letter (first class mail) or by email sent to an address where employees and/or affected parties can reasonably be expected to receive the disclosure or other, similar means. The notification, in clear and plain language, may contain the following elements:

• A description of the Incident that includes as much detail as is appropriate under the circumstances.

• The type of information that was impacted (e.g., number of individuals or records concerned) subject to unauthorized access and any foreseeable, likely consequences.

• Measures taken by Kredit to protect the information of employees and/or affected parties from further impact.

• A contact name and toll-free number, which employees and/or affected parties may use to obtain further information.

• A reference to the page on the Kredit website where updates may be obtained.

• Other elements as may be required by applicable law or whose inclusion the SIRT may otherwise consider appropriate under the circumstances.

Cooperation with External Investigators

If the SIRT considers it appropriate to inform law enforcement authorities or to retain forensic investigators or other external advisors, the following information shall be collected to provide to such authorities or investigators (to the extent known):

• Incident (date, time, place, duration, etc.)

• Person(s) under suspicion (name, date of birth, address, occupation/position, employment contracts, etc.)

• Computer and network log files pertaining to the Incident.

• “Ownership” details of any Information that is allegedly stolen, altered, or destroyed.

• Access rights to the computer system involved of the person(s) under investigation.

• Information obtained from access control systems (e.g., computer logs, CCTV, swipe card systems, attendance logs, etc.).

• Any action taken by the SIRT in relation to the computer systems concerned, including the date and time.

• A copy of applicable Kredit Data Privacy and Security Statement (“Statement”) in force at the time of the incident (if applicable).

• Any other documentation or evidence relevant to the internal investigation of the Incident.

Information Sharing and Media Relations

Security incident-specific information (e.g., dates, accounts, programs, systems) must not be provided to any unknown individuals making such requests by telephone or email. Any release of Security incident-specific information shall only be to individuals previously identified by the SIRT. If there is any doubt about whether information can be released, legal counsel should be consulted. Contact with law enforcement authorities shall only be made by legal counsel in consultation with the SIRT. In the event of an Incident, where members of the media make inquiries, employees are to be made aware that all requests for the release of information, press releases, or media interviews must be submitted to Kredit’s CEO. Kredit’s CEO, in consultation with the other members of the SIRT, shall determine whether it is appropriate to issue a media statement, hold a press briefing, or schedule interviews.

Follow Up

Events and Incidents shall be reviewed after identification resolution to determine where response could be improved. The SIRT will meet to review the Event or Incident record created, as necessary, and perform the following:

• Determine the root cause of the Incident and what shall be done to ensure that the root cause has been addressed.

• Create a “lessons learned” document and include it with the Incident Record.

• Evaluate the cost and impact of the Event or Incident to the organization using applicable documents and any other resources.

• Determine what could be improved.

• Communicate these findings to senior management for approval, as necessary, and for implementation of any recommendations made post-review of the Event or Incident.

• Carry out recommendations approved by senior management while ensuring that sufficient time and resources are committed to this activity.

• Close the Event or Incident.

Record Retention

The SIRT must ensure that all records relative to the Incident are retained and appropriate protections are applied to guard against the alteration or deletion of the incident record in accordance with Kredit’s Record Retention Schedule.

Periodic Evaluation of the Program

The processes surrounding incident response are periodically reviewed and evaluated for effectiveness. The evaluation also involves appropriate training of resources expected to respond to Events and Incidents, as well as the training of resources regarding Kredit’s expectation of them, relative to security responsibilities. Events and Incidents shall be recorded for tracking, analysis, and reporting purposes.

Training

On an annual basis, all Kredit employees will receive training on the Incident Response Plan to ensure they are familiar not only with the Plan, but also with their roles and responsibilities during an Incident as well as with the communication processes both inside and outside the organization.

Communication

The Kredit Incident Response Plan shall be communicated to employees via email and each employee must attest to their receipt and understanding of the policy. The policy is stored in Google Drive (Kredit Projects and Template Library) for employee reference purposes.

Control

On an annual basis, Kredit shall conduct an Incident Response Test to determine the effectiveness of the Incident Response Policy. The results of each phase of the Incident Response Test must be thoroughly documented for evidentiary purposes.

Violations

Failure to comply with the Kredit Incident Response Plan may undermine the organization’s ability to identify, contain, and eradicate threats to the integrity, confidentiality, and availability of systems and data and remain compliant with the Gramm-Leach Bliley Act Section. This can also impact the process of prosecuting any individual responsible for an incident. Failure to comply with this plan may result in disciplinary actions up to and including termination of employment, agreements, and possible litigation.

CHANGE SUMMARY

Purpose: Internal Policy

Category: Information Security Plan

Policy Name: Incident Response Plan

Event	Event Date	Event By	Date Reviewed	Reviewed By	Version
Creation and Implementation	10/25/2023	Colene McNinch, CCO			1.0