Incident Response

PURPOSE:

This Incident Response (IR) Policy establishes the framework, standards, and procedures for detecting, analyzing, containing, eradicating, recovering from, and conducting post-incident activities related to security incidents that affect the confidentiality, integrity, or availability of Idaho College of Osteopathic Medicine (ICOM) information assets, IT infrastructure, and services. The purpose of this policy is to ensure a swift, effective, and coordinated response to security incidents, minimizing damage, disruption, and recovery time. Effective incident response is crucial for protecting institutional data, maintaining operational resilience, complying with legal and regulatory obligations, and preserving the Institution's reputation. This policy applies to all suspected and confirmed security incidents involving the Institution's IT resources, including on-premises systems and cloud-based services (including SaaS applications).

SCOPE:

This policy applies to all suspected and confirmed security incidents that impact or could potentially impact the confidentiality, integrity, or availability of the Institution's information assets, IT infrastructure, and services. This includes, but is not limited to:

• Data breaches and data leaks
• Unauthorized access to systems or data
• Malware infections (viruses, worms, ransomware, spyware)
• Phishing attacks and social engineering attempts
• Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks
• Insider threats (intentional or unintentional)
• Policy violations with security implications
• Physical security incidents impacting IT infrastructure
• Loss or theft of institutional devices containing sensitive data
• Compromise of cloud-based services (including SaaS applications)
• Any event that compromises or could compromise the security of institutional information or systems.

This policy applies to all individuals who use, manage, or have access to the Institution's IT resources, including but not limited to:

• Faculty
• Staff
• Administrators
• Students
• Researchers
• Affiliates
• Volunteers
• Contractors
• Vendors
• Guests
• Any individual who becomes aware of a suspected security incident.

DEFINITIONS:

• Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
• Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.
• Availability: Ensuring timely and reliable access to and use of information.
• Incident: A violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices.
• Incident Response: The organized and coordinated approach taken to address a security incident.
• Incident Response Plan (IRP): A documented set of procedures for detecting, analyzing, containing, eradicating, recovering from, and conducting post-incident activity for security incidents.
• Incident Response Team (IRT): A designated group of individuals responsible for managing and coordinating the response to security incidents.
• SaaS Application (Software as a Service): A software delivery model in which software is hosted by a vendor and made available to customers over a network, typically the internet, usually on a subscription basis.
• Threat Actor: An individual, group, or organization that attempts to exploit vulnerabilities or cause harm to information systems or data.

POLICY:

Incident Response Plan (IRP): A detailed Incident Response Plan (IRP) will be developed, documented, and maintained to provide step-by-step guidance for handling various types of security incidents. The IRP will include: 

• Incident Response Lifecycle: Outline the six phases of the incident response lifecycle: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.
• Incident Severity Levels: Define a classification system for categorizing incidents based on their severity and potential impact (e.g., Low, Medium, High, Critical). Severity levels will guide the response priority and resource allocation.
• Incident Response Team (IRT): Identify the members of the Incident Response Team (IRT) and their specific roles and responsibilities. Include primary and backup contacts for each role.
• Communication Plan: Detail communication protocols for internal and external stakeholders during an incident, including notification procedures, reporting channels, and escalation paths.
• Specific Incident Playbooks: Develop playbooks or standard operating procedures (SOPs) for handling common incident types (e.g., malware infection, phishing attack, data breach). These playbooks will provide detailed steps for each phase of the response.
• Evidence Handling Procedures: Outline procedures for collecting, preserving, and documenting evidence related to security incidents in a forensically sound manner.
• Legal and Regulatory Requirements: Identify relevant legal and regulatory reporting requirements for security incidents (e.g., data breach notification laws, HIPAA breach notification rule, FERPA requirements) and outline procedures for complying with these obligations.
• SaaS Incident Response Considerations: Include specific procedures for addressing security incidents involving SaaS applications, such as:
  • Reporting incidents to the SaaS vendor.
  • Coordinating response activities with the vendor.
  • Accessing vendor incident response documentation and support channels.
  • Implementing institutional-side containment and mitigation measures.
• Contact Information: Include up-to-date contact information for the IRT members, relevant IT staff, legal counsel, marketing & communications, and external resources (e.g., law enforcement, cybersecurity vendors).

Incident Reporting: All suspected or confirmed security incidents must be reported immediately to the designated reporting channels. Reporting procedures will be clearly communicated to all users.

• Designated Reporting Channels: Specify the primary methods for reporting incidents (e.g., IT Help Desk phone number, dedicated email address, online reporting portal).
• Reporting Expectations: Emphasize the importance of timely and accurate reporting of any suspicious activity or potential security incident, regardless of perceived severity.
• No Retaliation Policy: Assure individuals that there will be no retaliation for reporting security incidents in good faith.

Incident Response Team (IRT): An Incident Response Team (IRT) will be established and will be responsible for managing and coordinating the response to security incidents.

• IRT Composition: The IRT will consist of representatives from key departments, including but not limited to:
  • Information Technology (IT)
  • Legal Counsel
  • Office of Institutional Effectiveness & Compliance
  • Marketing & Communications
  • Relevant academic or administrative departments (depending on the nature of the incident).
• IRT Roles and Responsibilities: Clearly define the roles and responsibilities of each IRT member, such as:
  • Incident Response Team Lead: Overall coordination and management of the incident response effort.
  • Technical Lead: Overseeing technical aspects of incident analysis, containment, eradication, and recovery.
  • Communications Lead: Managing internal and external communications related to the incident.
  • Legal/Compliance Lead: Ensuring legal and regulatory obligations are met.
  • Documentation Lead: Maintaining accurate records of all incident response activities.
• IRT Training and Preparedness: The IRT will receive regular training on incident response procedures, tools, and techniques. The IRT will also participate in incident response exercises and simulations to maintain preparedness.

Incident Identification and Analysis: Upon receiving a report of a suspected incident, the IRT will promptly initiate the identification and analysis phase to determine the nature, scope, and severity of the incident.

• Initial Assessment: Conduct an initial assessment to gather preliminary information and determine if a security incident has occurred.
• Triage and Prioritization: Triage and prioritize incidents based on the defined severity levels and potential impact.
• Detailed Analysis: Conduct a thorough analysis to understand the root cause, attack vectors, affected systems and data, and potential impact of the incident. Utilize logs, security tools, and forensic analysis techniques as needed.

Incident Containment: Once an incident is confirmed and analyzed, the IRT will take appropriate containment actions to limit the scope and impact of the incident and prevent further damage.

• Containment Strategies: Implement containment strategies based on the type and severity of the incident, which may include:
  • Isolating affected systems or network segments.
  • Disabling compromised accounts.
  • Blocking malicious traffic or IP addresses.
  • Taking systems offline.
  • Implementing temporary workarounds.
• Preservation of Evidence: Ensure that containment actions are taken in a manner that preserves digital evidence for further analysis and potential legal proceedings.

Incident Eradication: After containing the incident, the IRT will take steps to eradicate the threat and remove any malicious components or unauthorized access.

• Eradication Activities: Eradication activities may include:
  • Removing malware from infected systems.
  • Patching vulnerabilities that were exploited.
  • Rebuilding compromised systems.
  • Changing compromised passwords.
  • Revoking unauthorized access.

Incident Recovery: Once the threat has been eradicated, the IRT will initiate recovery procedures to restore affected systems, applications, and data to a secure and operational state.

• Recovery Procedures: Recovery procedures may include:
  • Restoring data from backups.
  • Reconnecting isolated systems to the network.
  • Verifying system functionality and data integrity.
  • Conducting post-eradication security scans.
• Phased Recovery: Implement a phased recovery approach, prioritizing the restoration of critical systems and services first.

Post-Incident Activities (Lessons Learned): After the incident has been resolved and systems have been recovered, the IRT will conduct a post-incident review to analyze the incident, identify lessons learned, and improve the Institution's security posture and incident response capabilities.

• Post-Incident Meeting: Conduct a post-incident meeting with the IRT and relevant stakeholders to review the incident timeline, actions taken, effectiveness of the response, and any challenges encountered.
• Lessons Learned Documentation: Document the lessons learned from the incident, including root causes, contributing factors, areas for improvement in policies, procedures, and controls, and recommendations for preventing similar incidents in the future.
• Policy and Procedure Updates: Update the Incident Response Plan, security policies, and procedures based on the lessons learned from the incident.
• Communication of Lessons Learned: Communicate relevant lessons learned to the broader institutional community to enhance security awareness and preparedness.

Legal and Regulatory Compliance: The Institution will comply with all applicable legal and regulatory requirements related to security incidents, including data breach notification laws and reporting obligations.

• Data Breach Notification Procedures: Follow established procedures for assessing and reporting data breaches in accordance with applicable federal and state laws (e.g., HIPAA Breach Notification Rule, state data breach notification laws).
• Regulatory Reporting: Comply with any other regulatory reporting requirements related to security incidents (e.g., reporting to funding agencies, accrediting bodies).

Policy Exceptions: Exceptions to this Incident Response Policy may be granted in limited circumstances by the Chief Information Officer or designated authorization authority, with appropriate justification, documented risk assessment, and approved compensating controls. Exceptions should be rare and subject to periodic review.

ENFORCEMENT:

Enforcement of this Incident Response Policy is the responsibility of all managers, supervisors, IT staff, security personnel, and all individuals who use the Institution's IT resources. Failure to report suspected incidents, hindering incident response efforts, or violating this policy may result in disciplinary actions, up to and including warnings, suspension of system access, and termination of employment or access privileges, consistent with other institutional policies and procedures. The Information Technology Office will monitor compliance with this policy and investigate reported violations.

POLICY REVIEW AND UPDATES:

This Incident Response Policy and the associated Incident Response Plan will be reviewed and updated annually, or as needed to reflect changes in the threat landscape, technology, regulations, best practices in incident response, organizational structure, or lessons learned from incident response activities and exercises. The Information Technology Office is responsible for coordinating policy reviews and updates, in consultation with the IRT and relevant stakeholders.

PRIMARY POLICY OWNER:

Chief Information Officer

APPROVAL:

Effective: 7/8/25

Last Reviewed: 7/8/25

Review Requirement: Annual

CROSS REFERENCE AND SUPPORTING DOCUMENTS:

Information and links to other policies or supporting documents referenced within this policy.