ITS Incident Management Plan

Effective Date: 7/2/2025

Issuing Authority: CTO

Table of Contents

• Table of Contents
• Incident management Plan
  • Introduction
  • Purpose of Incident Response Plan
  • Scope of Incident Response Plan
  • Purpose of Incident Response Team
  • Objectives of Incident Response Team
• Incidents
  • Incident Categories
• Responding to an Incident
  • Organization of the Incident Response Team
  • Roles
    • Incident Manager
    • Communication Lead
    • Technical Lead
  • Other Roles
    • Safety Officer
    • Liaison Officer
    • Incident Response Team Roles Alignment with NIMS Roles
  • The Incident Response Process
• Revising the Incident Response Plan
• APPENDIX A. related Documents
• APPENDIX B. References
• APPENDIX C. List of Sources for Alerts or Notifications of a Threat
• Revision History

Introduction

Several factors necessitate the establishment of an Information Technology Services (ITS) incident response plan for Carleton College (the College):

1. Avoiding all potential operational failures caused by hardware failure, software bugs, resource exhaustion, or human error is impossible.
2. College data held in institutional systems and networks is at risk of various persistent security threats. Any unauthorized loss or disclosure of data is undesirable, and reasonable efforts should be made to respond and limit the impact of security incidents.
3. The College is obligated from a regulatory and statutory perspective to make reasonable efforts to be prepared to marshal a timely response to incidents.
4. The College must rely on third parties for our IT services. For example, Internet service, SIP (telephone) service, and electrical power are services that are (currently) beyond the College’s ability to create on its own. Moreover, increasingly, the College relies on third parties for Software- and Platform-as-a-Service services. These services are individually subject to the same operational and security concerns as the College.

Some incidents caused by operational failures can be mitigated by, for example, regular hardware and software replacement; regular hardware, software, and firmware patching; and the implementation of clustering and high-availability architectures. The frequency of human-error-caused incidents can be reduced through preparation, planning, user education, and testing. How robust these efforts are is dependent on the level of funding. Campus leadership makes funding decisions as it relates to hardware, software, and staffing levels.

IT leadership will recommend to campus leadership reasonable measures to operationally support and secure institutional data and systems. Campus leadership supports these measures by approving continued funding of the IT department and increasing the IT budget as warranted because of changing operations and security requirements.

The following examples of computer security incidents are now commonplace:

• A computer virus is copied to a computer; within minutes, hundreds of other computers are infected over the campus network; recovery takes several staff members and several days.
• Backups infected with viruses result in re-infected systems, requiring more time and expense.
• Vulnerabilities in software are discovered that permit unauthorized entry; explicit instructions on how to exploit the vulnerability quickly become known.
• System intruders copy confidential data and use it for criminal activities.
• Outbreaks of viruses or system penetrations appear in the press, causing embarrassment, financial loss, and possible loss of public confidence.

These situations could have a significant impact to the College, such as unnecessary expenses, loss of productivity, significant damage to systems, damage to our community members, damage to our reputation, or exposure to litigation. These risks necessitate a workable plan to minimize potential damage by handling an incident swiftly and deliberately.

Purpose of the Incident Response Plan

An incident response plan brings needed resources together in an organized manner to deal with an adverse event related to the safety and security of the College’s computer resources and our members’ data. The incident response plan complements other plans and policies such as the institutional emergency response plan, the IT continuity of operations plan (business continuity/disaster recovery), the outage communications plan, the information security policy, and others. Collectively, these guide the continuity of critical instructional and business services, the recovery of systems or services in the event of a significant outage, the protection of critical information, and the prompt notification of those individuals actually or potentially affected by a breach.

The College will make all reasonable efforts to protect such information under its control from unauthorized access, use, disclosure, deletion, destruction, damage, or removal. Though reasonable efforts are made to protect resources and data, there exists the possibility that resources and data under the control of the College may be breached. As a result, the purpose of this incident response plan is for the College to have a reasonable and appropriate breach notification procedure or action plan in place should security procedures not prevent a breach. This plan comports with existing laws that address notice requirements for individuals and entities that may actually or potentially be affected by unauthorized access or breach.

Scope of the Incident Response Plan

This plan is designed for incidents where the response is entirely the responsibility of the ITS department. If an incident requires a response by other departments or a whole campus response, this plan should guide the ITS response while being subordinate to the Campus Emergency Response Plan.

Purpose of the Incident Response Team

The purpose of ITS Incident Response Team is to:

• Protect the College’s information assets
• Provide organization to handle incidents
• Comply with state and federal security requirements
• Prevent the use of the College’s systems in attacks against other systems (which could cause us to incur legal liability)
• Minimize the potential for negative exposure

Objectives of the Incident Response Team

The objectives of ITS’s Incident Response Team are to:

• Limit immediate incident impact to services, systems, and clients
• Initiate notification of the incident to affected users
• Recover from the incident
• Notify appropriate law enforcement agencies and those persons affected by the breach, if applicable, and required or deemed appropriate 
• Determine how the incident occurred
• Mitigate vulnerabilities if applicable
• Avoid further incidents
• Update policies and procedures as needed
• Communicate with peer communities

Incidents

Incident Categories

An incident will be categorized as one of three severity levels. These severity levels are based on the impact on the College. They can be expressed in terms of financial impact, impact on services or performance of our mission functions, impact on the College’s image, or impact on trust by its members, annuitants, participants, employees, etc. Table 1 provides a listing of the severity levels and a description of each severity level.

Incident Categories

Table 1: Severity Levels

Responding to an Incident

There are generally six stages of response:

1. Preparation—Knowing how to respond to an incident BEFORE it occurs can save valuable time and effort in the long run.
2. Identification—Identify if an incident has occurred. If one has occurred, appropriate resources can be assigned to the incident.
3. Containment—Containment involves limiting the scope and magnitude of an incident. Because so many current incidents involve malicious code, incidents can spread rapidly. This can cause massive destruction and loss of information. As soon as an incident is recognized, immediately begin working on containment.
4. Notification—As soon as reasonably possible, notification should be sent to affected users. For high severity (and some medium severity) events, College leadership should be notified during the identification phase.
5. Eradication—Removing the cause of the incident can be a complex process. It can involve virus removal, conviction of perpetrators, or dismissal of employees.
6. Recovery—Restoring a system to its normal business status is essential. Once a restore has been performed, verifying that the restore operation was successful and that the system is back to normal is also essential.
7. Follow-up—Follow-up activity includes preparing a post-incident report, supporting any efforts to prosecute those who have broken the law, supporting institutional disciplinary action for a responsible employee or student, or changing any College policies that need to be revised.

Organization of the Incident Response Team

Predetermined teams will participate, depending on the characteristics of the incident, to adequately respond to an incident. As the situation develops and the impact becomes more significant, it may be necessary to delegate roles to other people or commission additional designees to serve in additional required roles.

Roles

Incident Manager

The first staff member to become aware of an incident is the de facto incident manager until the appropriate incident manager is identified and assumes leadership. The incident manager is responsible for all aspects of incident response until additional roles are designated. This person remains the incident manager until purposely relieved of this responsibility. As the impact of an incident increases, it becomes necessary to bring more resources to bear on the problem.

The incident manager is responsible for:

• Setting priorities and determining incident objectives and strategies to be followed
• Establishing the organization needed to manage the incident
• Approving the plan of action
• Communicating with College Leadership
• Coordinating activities between incident team members
• Requesting resources, that is, supplemental staff
• Ensuring post-incident reports are completed
• Ensuring notifications to affected users are accomplished
• Coordinating with other College departments or organizations as required
• Closing the incident

Communications Lead

The communications lead is responsible for both internal communications within the ITS department as well as communications sent to affected users:

• Determining, according to direction from the incident manager, any limits on information release
• Developing accurate, accessible, and timely information for use in notifications
• Maintaining current information on the incident
• Defining channels for internal and external communications
• Making information about the incident available to the incident personnel
• When a high severity incident is identified, the Communications Lead and the Incident Manager will collaborate with the VP for Communications on the manner and content of information released to public media

Technical Lead

The technical lead is primarily focused on containing and resolving the incident. The technical lead is responsible for:

• Assuring the safety of operations personnel
• Managing operations personnel, activities, and priorities
• Developing the plan of action
• Supervising the execution of the plan of action
• Requesting additional resources to support operations
• Releasing resources from active operational assignments
• Making or approving changes to the plan of action
• Maintaining close contact with the incident manager, operations personnel, communications lead, and other resources assigned to the incident

Other Roles

Other roles may need to be assigned in a high-severity incident or one that continues for an extended period. These include:

Safety Officer

The safety officer is responsible for:

• Ensuring incident team members are fed, rested, and relieved as appropriate
• Identifying and mitigating hazardous situations
• Ensuring everyone on the incident team is aware of safety issues through appropriate messages and briefings
• Exercising emergency authority to stop and prevent unsafe acts
• Reviewing the plan of action’s safety implications
• Initiating preliminary investigations of accidents within the incident area

Liaison Officer

For most high-severity incidents, the ITS Incident Manager (typically the Chief Technology Officer) serves as the liaison between the ITS incident team, the Cabinet, other College departments, and external agencies. In a sufficiently extensive or prolonged incident, it may be helpful to assign an additional individual to focus on liaison activities. 

Incident Response Team Roles Alignment with NIMS Roles 

These roles align with roles in the Federal Emergency Management Agency (FEMA) National Incident Management System (NIMS) Incident Command System (ICS). See Table 2. This mapping is provided for reference, should further information regarding the roles and responsibilities of an incident response team member be desired.

NIMS Roles

Table2. Incident Management Plan – NIMS ICS Roles Alignment

In a sufficiently prolonged or extensive incident, it may be necessary for other roles to be assigned as described in the NIMS ICS. These include a planning officer, logistics officer, and finance/administrative officer. Similarly, it may be necessary for the technical lead and assigned operations resources to take the form of an operations section, or for the planning, logistics, finance/administrative functions to expand to a team or section in NIMS terminology. These teams may need to be broken into organizational groupings as appropriate. For more information about these roles and groupings, consult the NIMS ICS.

The Incident Response Process

Incident response follows the following process.

1. Identify an incident. Incidents may first be identified by customer reports via the ticketing system or other means of communication. Incidents may be identified via monitoring or alerting systems.
2. The first responder to the incident is the de facto Incident Manager and is responsible for Incident Manager, Technical Lead, and Communication Lead responsibilities until these responsibilities are delegated to others.
3. Work the incident. Initially, the Incident team needs to identify affected services, identify affected users, determine a plan of action, and estimate the time until services are restored.
4. Communication. It is important to notify leadership and affected users at the earliest opportunity. Customer notifications should, if possible, set expectations for the restoration of services. Initial communication should not be unduly delayed if the scope, impact, and estimated time to restoral cannot be quickly or easily determined. For more information, consult the communications plan.
5. Resolve the incident, continue to work the incident, or escalate the incident. Resolve the incident through the restoration of services or the implementation of a workaround. If the incident is resolved, proceed to after-action activities; otherwise, continue to work the incident. Escalation primarily involves augmenting existing teams or designating additional roles to effectively manage incidents that are increasing in complexity or duration.
   • Consider staff alignment and augmentation.
     1. Delegate initial incident roles to others (Incident Manager, Technical Lead, and Communications Lead)
     2. Expand the Technical Lead role to an operations team to work multiple courses of action in parallel
     3. Add other roles to provide essential support and/or ensure staff rest and rotation (e.g., Planning, Liaison, or Safety Officer)
     4. Consider involving vendor resources or other outside expertise
   • While the incident remains unresolved, repeat as necessary:
     Step 1. Work the incident.
     Step 2. Communicate with leadership and affected users as appropriate.
     Step 3. Resolve the Incident or consider escalation.
6. Post-resolution activities.
   • Send a final communication to affected users. Provide as much information about the cause of the incident, steps taken to restore services, and any remaining impact as appropriate. Instruct users to contact the Help Desk if there are any remaining questions, concerns, or any lingering impacts.
   • Complete a post-incident report shortly after the conclusion of the incident. The post incident report should include:
     1. A detailed description of the incident
     2. A root cause, if known
     3. Affected services and users
     4. Actions taken to restore services
     5. Any required follow-up actions, including a due date when the activity should be completed
   • Follow-up actions should be tracked and completed within a reasonable amount of time.

Revising the Incident Response Plan

This plan will be reviewed annually. Additionally, the plan will be evaluated and revised as necessary following a medium or high severity security event.

APPENDIX A. Related Documents

Campus Incident Management Plan

IT Emergency Communications Plan

IT Security Investigations Policy and Standard

Post Incident ReportIncident-at-a-Glance (with operational details for communication processes)

APPENDIX B. References

FEMA National Incident Management System

Standards For Safeguarding Customer Information, 16 Code of Federal Regulation 314.4(h)

IS-700.B: An Introduction to the National Incident Management System

APPENDIX C. List Of Sources For Alerts Or Notification Of A Threat

List of Sources

Revision History

Data Classification Revision History