Incident Management and Response

Table of Contents

Getting Started

Information security incidents are inevitable. The goal of an effective information security incident management strategy is to process incidents as effectively as possible and minimize the impact of the incident on the institution. If you are just getting started with your information security incident response program, start thinking about the following:

  1. Define what constitutes an information security incident on your campus and think about an incident classification severity scheme.

  2. Think about the types of information security incidents that may require special handling and leadership involvement (vs. those events can be handled routinely by staff).

  3. Identify and establish essential roles and procedures needed for effective incident management.

  4. Evaluate the technical and operational capabilities of your information security or IT teams to detect and respond to information security incidents.

  5. Consider how campus and IT leadership support can be gained to formalize effective incident management processes.

  6. Formulate guidance for effectively addressing incidents throughout their lifecycle.

  7. Create effective communication, coordination, and incident reporting plans.

  8. Review the legal and contractual communication requirements associated with institutional data types that may be involved in information security incidents.
  9. Adapt and learn from security incidents and strive for continual improvement by identifying and planning for training needs and enhancement of response capabilities.

Top of page


The reality of security incidents, breaches, and data loss have become all too familiar to a growing number of colleges and universities. Information security incident management programs (sometimes also called information security incident response programs) are required to help institutions respond to information security incidents that compromise the confidentiality, availability, and integrity of an institution’s information technology resources and data. An institution’s failure to plan in advance for handling information security incidents is a mistake and can jeopardize the institution.

An effective information security incident management program includes 4 basic stages: Preparation; detection and analysis; containment, eradication, and recovery; and post-incident review. The National Institute of Standards and Technology SP 800-61, Computer Security Incident Handling Guide, describes the "Incident Lifecycle" using this flowchart:

From NIST SP 800-61, Computer Security Incident Handling Guide, Figure 3-1

There are a number of good industry references for effective information security incident management programs, including the NIST document referenced above and ISO/IEC 27002 domain 16 (Information Security Incident Management). This chapter supplements those resources by providing a high-level overview of incident management approaches from an institutional perspective, a list of recommended tools for incident handlers, links to example practices at selected institutions, and other helpful guidance.

Top of page

Management of Information Security Incidents and Improvements (ISO 16)

Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.


An institution's information security incident response management program is evidenced by policies and incident handling procedures. These documents should be clear and concise, describing the steps all campus members (from end user to incident response staff to leadership) must take in response to an actual or suspected incident. Ideally, these documents are prepared well in advance of being needed. During this preparation stage, the institution identifies the resources needed for incident response capabilities, ensures that it has individuals who are properly trained and ready to respond to information security incidents, and develops and communicates the formal detection and reporting processes to campus.

Many institutions evidence their commitment to their information security incident management programs via an incident response policy. Common incident response policy sections include:

Sample incident response policies can be found on the Information Security Policy Examples page in this Guide.

During the preparation stage it is also important to consider creating resources to supplement the institution's information security incident response policy. Supporting documents might include:

Thinking about incident response training and education is very important during this preparation stage. Not only do campus end users need to be trained on their reporting roles and responsibilities, but the operational incident response team and campus leadership needs to be trained on their roles too. In some instances, members of the incident response team may require specialized training on using forensics analysis or other data examination and recovery tools.

Top of page

Detection and Analysis

Designing an effective mean to detect information security incidents is also essential. Information security incidents can be reported by end users, and they can also be detected (and reported) via trained IT personnel. This is why it is so important that all campus personnel be trained on the proper way to report a suspected information security incident.

In addition to reporting, technical controls must be implemented for the automated detection of security events, coupled with as near real-time reporting as possible, to investigate and initiate response activities. Common controls include monitoring server logs for signs of unauthorized access, monitoring firewall or router logs for abnormal events, and monitoring network performance for spikes in traffic. Institutions may also implement host and network intrusion detection/prevention systems. Data aggregation tools, such as a security information and event management (SIEM) tool, can help manage data from multiple sources to generate alerts and even take action to stop malicious activity.

In addition to detecting an incident (through a number of mechanisms), it is imperative that the information security incident be timely assessed to determine the types of information technology resources and institutional data potentially involved in the incident, and to understand the severity level of the incident (ranging from low to high severity). During this analysis, the operational incident response team will also try to understand the scope of the suspected incident. For example, is the incident confined to one unit, one department, a campus building, an entire campus, multiple campuses, or an entire system (if applicable)? The team will also try to understand how many resources (services, systems, or applications) or how much data (usually counted in records or accounts per person) may be involved. They will try to determine the type of data involved in the suspected incident (e.g., is it personally identifiable to an individual, protected by law, is intellectual property or research data involved, etc.).

They will also attempt to assess the urgency of the suspected incident. Is it an active problem, threat, or an event-in-progress? Was the problem discovered after the fact? Does the suspected incident involve use of an account rather than a system? Does it involve the safety or privacy of individuals?

All data gathered during this detection and analysis stage will help inform prioritization of the incident and help inform the activities performed in the next stage. Most institutions will have forms and checklists to walk them through the data gathering process. It is also during this activity that the institution might start creating a record or log regarding the suspected incident, including whether or not the suspected incident is confirmed as an actual information security incident to which the institution must respond.

Containment, Eradication, and Recovery

It should be noted that most incident response steps don’t happen sequentially, or with clear delineations between tasks. Once a suspected incident is confirmed, sometimes detection and analysis, and containment, eradication, and recovery activities may all happen at the same time or with a speed that suggests that they are happening at the same time. This is normal depending on the scope and severity of the underlying information security incident, as well as the maturity of the institution's information security program and incident handling capability.

During this phase, operational incident response teams may do these types of containment activities:

Operational incident response teams may do these types of eradication and response activities during this phase:

The following Information Security Guide resources may be helpful during this phase:

Post Incident Review

The post incident review phase is critically important and oft overlooked. During this phase the operational incident response team, and campus and IT leadership come together after an information security incident is closed (or active incident response activities have concluded) to identify lessons learned and how to better handle future information security incidents. Activities in this stage may include:

During this phase, campuses may also update their information security incident response metrics. The purpose of incident response metrics is to help the institution understand the major causes and sources of information security incidents, to measure damage caused by incidents, and to observe trends in both. Metrics may include the total incidents handled, time spent on incidents, the number of different types of incidents, and the number of systems impacted. Some useful incident response metrics to measure over time include:

Top of page


Top of page






2014 Cybersecurity Framework

HIPAA Security

27002:2013 Information Security Management
Chapter 16: Information Security Incident Management

800-53: Recommended Security Controls for Federal Information
Systems and Organizations
800-61: Computer Security Incident Handling Guide
800-83: Guide to Malware Incident Prevention and Handling
800-86: Guide to Integrating Forensic Techniques into Incident Response
800-94: Guide to Intrusion Detection and Prevention Systems Rev 1


Req 11
Req 12


45 CFR 164.308(a)(6)

Top of page

Questions or comments? Contact us.

Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).