Incident Response Process

Roles and Responsibilities in the Event of an Incident

Organizational leadership will be provided by the Chief Information Officer or designee. The CIO or designee are responsible for determining the scope and impact of an incident, and will trigger initiation of the IT Disaster Recovery Plan and may convene the Data Security Breach Review Panel defined in Policy #860 Information Security, as appropriate.

Per OU Policy #890, release of information to outside agencies, including any law enforcement groups, must be coordinated with the explicit permission of the Office of Legal Affairs.

If review indicates that a data breach has occurred, the Data Breach Security Review Panel defined under Policy #860 Information Security will be convened by the CIO or designee. Breach response guidelines from the insurance provider will be provided and reviewed by the panel. Immediate action will be taken by the CIO and University Risk Manager to contact the cyberliability insurance firm and all action steps will be directed under the university cyberliability insurance and consultant agreement. Documentation for working with the insurance provider is in the UTS Incident Access Response - Google Team Drive, Documentation folder.

If a data breach involving payment card data is discovered, the CIO or designee, working with the Information Security Officer and the university cyberliability insurance consultants, will immediately follow payment brand contact procedures before any action is taken:

Visa Responding to a Data Breach

Master Card Account Data Compromise User Guide

Stage I: Notification of an Incident

An Information Technology Incident can be reported in several ways, including:

  • An email to the University’s abuse contact at .

  • An email to the University Technology Services contact at or to any individual staff member in UTS.

  • An email, telephone call, or in-person visit to any university helpdesk location will be transferred to UTS Projects.

  • A request from the OU Police Department or authorized law enforcement agency.
  • A request from the Office of Legal Affairs.
  • An observation or analysis performed by a systems administrator, system engineer or other UTS professional.

In all cases, a ticket is created in the internal UTS ticketing system. This ticket is used for all tracking, analysis, and reporting functions. All incidents will proceed to the next stage.

Stage II: Initial Incident Evaluation

After the initial notification, UTS staff will engage the necessary resources to perform a cursory evaluation to identify the scope and impact of the incident. Related to this are guidelines for Investigations. The following criteria are evaluated, in order of importance:

  1. Determine level of preservation required before any item is touched or reviewed. Do not turn a computer or other electronic device off; anything with an on/off switch should be left on. Note that even reviewing some files will corrupt the evidentiary quality of the material.
    1. Does active memory need to be imaged or captured?
    2. Does the system require immediate removal from the network?
    3. Are there accounts (user or system) that require immediate protection by disabling or password change?
  2. Determine severity and criticality. Assess the urgency of the event.
    1. Is it an active problem, a potential threat, or event-in-progress?
    2. Was the problem discovered after the fact?
    3. Is the intrusion or exposure dormant, active, or complete?
    4. Does this involve the safety or privacy of individuals, including personally identifiable information?
  3. Determine scope and impact.
    1. Is there data loss or damage of data?
    2. Is there evidence of data breach, probability of access by unauthorized parties, or unauthorized exposure of data?
    3. What data are involved and what data classification covers the exposed data? Are original intellectual property or externally funded grant research data involved? Data loss can be classified as one of the following, per IT Policy #860 Information Security definitions:

      1. Confidential Data, including Personal Health Information, Personally Identifiable Information, and Payment Cardholder Information.
      2. Operation Critical Data
      3. Unclassified Data
    4. Identify the method by which data loss or exposure occurred.
    5. Identify the time-frame of affected data loss or exposure.
    6. Approximate number of lost files or records.
    7. Assess probability that data were accessed by unauthorized parties.
    8. Is a single edge device (desktop computer, laptop computer, storage drive, smartphone) involved, or are multiple devices involved?
    9. Were the device or devices used in an University Organized event or registered to a Univesity Event account?
    10. Is a server with multiple files involved?
    11. Is a single user or account involved, or are multiple accounts involved?
    12. Are system-level accounts involved?
    13. Is there a loss or attempted loss of service?
    14. Is there a loss or failure of hardware?
    15. Is there a breach of University IT Policy?
    16. Was a device lost or stolen?

If none of the above conditions are met, then an incident did not take place. The tracking ticket is updated with all relevant information and analysis, and then closed.

Stage III: Response Activation

For any incident matching the criteria listed above:

  1. Notify the Data Security Breach Review Panel identified in University Policy #860 Information Security. Note breach reporting deadlines in communications.

  2. For Confidential Data, identify the nature and extent of the data involved, the exposure to unauthorized individuals, the identity of unauthorized individuals, and whether Confidential Data were acquired, viewed, and utilized.
  3. If login credentials were compromised for an individual in the university community, initiate a Red Flags notice following the university Red Flags policy Policy #412 Detection of and Response to Identity Theft Red Flags. UTS will notify Student Business Services based on this policy.

  4. Involve necessary UTS personnel.
  5. Complete the Checklist for Lost, Stolen or Missing Computer, Table, Smartphone, or Other Media Storage Device found at the end of this document, if a device was involved.

Stage IV: Return of Service

Post an informational message on the status of service on the UTS homepage, to be updated every two hours (unless specifically noted), until service is returned. Preserve all material evidence as quickly as possible. Then return services to normal operations, unless under other orders from the Office of Legal Affairs. Document the extent of risk to Confidential Data, whether the risk has been mitigated, and note whether exposed data have been fully retrieved, destroyed, or reconfigured to be meaningless (i.e., changing identification numbers, changing passwords, closing accounts, etc.).

Stage V: Incident Response and Containment

Please proceed to each section that applies to the incident, based on the criteria identified from the previous stages.

  1. All incidents:

    1. Identify encryption strategies implemented and in use.
    2. Based on the identified data involved in the incident, create contact file for breach notification process, if applicable.
    3. Notifications will be created using the templates as a guideline, and distributed with the assistance of the Office of Risk Management.
    4. Gather and preserve all relevant information, disk images, access logs, system logs and any other material.
  2. Loss or Exposure of Data:

    1. Create an incident tracking record, with careful attention to incident handling and change-of-hands.
    2. Review the incident details with the Data Security Breach Review Panel, with counsel from the Office of Legal Affairs. These individuals will be kept informed during the Incident Review process.
    3. Determine the scope and impact of the data loss.
    4. Work with the Data Security Breach Review Panel on the appropriate notification plan for legal requirements, vendors, banks and other organizational entities.
  3. Loss of Service

    1. In the case of an attempted loss of service (such as a failed Denial of Service attack), take preventative measures to remove the issue attempting to cause the loss of service.
  4. Loss or failure of hardware

    1. If the hardware has been stolen, identify the data stored the stolen device. Handle incident as a loss of data incident. Complete the Checklist for Lost, Stolen, or Missing Computer, Smartphone, or Other Media Storage Device below.
    2. If there is a loss of service and data have been temporarily lost, but can be recovered from backup systems, place informational message on UTS homepage during the duration of the service loss when feasible.
    3. If data have been permanently lost, create and distribute a notification using the notification template.



DOCUMENT: This document is authorized and maintained by the Office of the Chief Information Officer, University Technology Services.

July 2018