IT Security Incident Response Policy
The Information Technology (IT) Security Incident Response Policy defines the responsibilities of KU Lawrence campus and all reporting units staff when responding to or reporting security incidents.
This policy applies to members of the Computer Security Incident Response Team (CSIRT) and those members of the University administration involved in security incident response.
The IT Security Incident Response Policy defines the responsibilities of KU Lawrence campus staff when responding to or reporting security incidents. It delineates roles within the Computer Security Incident Response Team (CSIRT) and outlines which members of University administration should be involved in different types of security incidents.
Roles and responsibilities:
IT Security Officer—The IT Security Officer is responsible for assessing the initial scope of a security incident, assembling the Enterprise Incident Management Team, and appointing the Incident Manager.
Incident reporting—All members of the University community are required to report actual or suspected security incidents. All suspected security incidents should be reported to the KU Customer Service Center at 785-864-8080 or email@example.com.
Incident manager—This role is designated by the IT Security Officer and will lead the response to the incident. This is a technical role and will coordinate the work of log collection, evidence preservation, and analysis activities.
Enterprise Incident Management Team:
When a breach of Category 1 data has been declared, the following University administration roles will be added to the incident response team:
- Senior administrator for impacted unit(s)
- Chief Information Officer
- IT Security Officer
- Representative from the Office of General Counsel
- Director of Security
- Director of Strategic Communications
- Others on an as-needed basis
The Enterprise Incident Management Team will work with the Director of Strategic Communications to determine when and how to inform individuals outside the EIMT regarding the incident.
Members of the Enterprise Incident Management Team and all IT staff shall receive annual incident response training. Tabletop exercises recreating a significant security incident will be conducted at minimum every two years.
Incident Severity Levels:
Incident response will be addressed based on the severity of the incident. Incident severity takes several factors into account: sensitivity of the data involved, number of end users impacted, and its overall impact on the ability of the University to fulfill its mission. Incident severity also will be used to determine who manages an incident, who is informed about an incident, and the extent and immediacy of the response to the incident.
A security incident will be considered “high” if any of the following characteristics are present:
- Threatens to impact (or does impact) systems critical to the University’s ability to function normally. This includes but is not limited to: email, courseware, human resources, financials, internet connectivity, or portions of the campus network
- Poses a serious threat of financial risk or legal liability
- Threatens to expose (or does expose) Category 1 data as defined by the Data Classification Policy
- Threatens to propagate to or attack other networks, or organizations internal or external to the University
- Terroristic threats or other threats to human life or property when received by the IT Security Office
A security incident will be considered “medium” if any of the following characteristics are present:
- Threatens to impact (or does impact) a significant number of systems or people. The University can still function, but a group, department, unit, or building may be unable to perform its mission
- Systems impacted contain only Category 2 and/or Category 3 data
- Impacts a non-critical system or service
Low severity incidents have no characteristics from the “medium” or “high” categories and may include the following:
- Only a small number of people or systems are impacted
- Systems impacted contain only Category 3 data
- Little to no risk of the incident spreading or impacting other organizations or networks
Incident Response Summary Table:
The following table summarizes how IT security incidents will be handled based on severity. It includes response times, who will manage each type of incident, and reporting requirements.
Who to Notify
Incident Report Required?
IT Security Officer
IT Security Officer or Incident Response lead (ITSO)
If requested by IT Security Officer, CIO, or other administrator
Next business day
Incident Response lead (ITSO)
Failure to report an information security incident may subject the user to disciplinary action including, but not limited, to suspension of the user’s access to electronic information resources. Users also should be aware of other possible consequences under University or Kansas Board of Regents policies and federal, state, or local laws, particularly those related to computer crime and copyright violation.
Chief Information Officer
1001 Sunnyside Ave.
Lawrence, KS 66045
A security incident is defined as any actual or suspected event that may adversely impact the confidentiality, integrity, or availability of data or systems used by the University to process, store, or transmit that data. Examples of events that could constitute a security incident include:
- Unauthorized access to data by an outsider or insider not authorized to access that data
- An endpoint (desktop, laptop, server, or mobile device) infected by malware. “Malware” is a broad category encompassing Trojans, worms, viruses, ransomware, and other malicious programs
- Reconnaissance activities such as scanning the network for security vulnerabilities when scans are performed by outsiders or insiders not authorized to perform such scans
- Denial of Service attacks (performed by outside or inside entities)
- Web site defacements
- Violations of KU IT security policies
- Unpatched vulnerabilities on systems connected to the KU network
- Discovery of an unregistered or non-centralized server in violation of the Server Hosting Policy.
05/22/2018: Uploaded new policy into Policy Library.