This plan outlines the most general tasks for Incident Response.  It will be supplemented by specific internal guidelines and procedures that describe the use of security tools and communication channels. These internal guidelines and procedures are subject to amendment as technology changes. It is assumed that these guidelines will be documented in detail and kept up-to-date.

Incident response process

In addition to documenting procedures, all Information Technology managers shall become familiarized with the incident response process to recognize and report incidents as quickly as possible. All faculty and staff are encouraged to report suspected information security incidents as quickly as possible.

Incident Management guidelines and supporting Incident Management (IM) toolkit is provided below:

Incident identification

The Information Security department maintains and utilizes several tools that scan the University’s environment and network traffic, looking for threats. Depending on the severity of found threats or vulnerabilities, they may warn affected users, disconnect affected machines, or apply other mitigations.  In the absence of indications of sensitive data exposure, the information security department communicates vulnerabilities to the network/IP owner identified in the IPAM database ( and pursues available technology remedies to reduce that risk.

Additionally, the University at large may identify and report suspicious activities, adverse events, or running malicious code. The affected Unit may call an incident on their own or may work with Information Security to formalize the incident if required.

Containment of the incident and preservation of evidence

Where any data or other artifacts are collected in the investigation, it is imperative to retain those for forensic review and establish a chain of custody. This evidence might be used in litigation should it become necessary.

Communication plan and prioritization

All units shall make the first attempt in classifying incidents according to the severity matrix listed in previous sections of this plan. If incidents are deemed medium or high severity, they need to be reported to the Institutional Security Response Team ( for awareness, assistance and/or escalation to the CISO. The Insititutional Team can also assist in the classification of the incident if required.

Incident Response teams shall document their guidelines for interactions with stakeholders regarding incidents and prioritize incidents with the highest severity level. During incident handling, the organization will need to communicate with multiple stakeholders. Because these communications often need to occur quickly, Incident Response teams shall predetermine communication guidelines.

The incident manager will typically have the responsibility to handle communications as part of the incident response  process. In case a CSIRT was established to handle a particular incident, the incident manager will prepare the communication in coordination with the team and target the appropriate audience. The workflow and table are below.

Incident severity Target response time* Incident Manager Who to notify? Incident reporting required?
High Immediate IT Security Officer or Delegate
  • IT Security Officer
  • IT Administrator
  • Unit administrator
  • Unit Representative
  • CIO
  • CISO
  • Privacy Officer
  • Institutional Incident Response team
  • Others on a need-to-know basis

(daily emails informing progress, formal incident report upon closure, lessons learned report)

Medium 4 hours IT Security Officer or Incident Response Lead
  • IT Security Officer
  • IT Administrator
  • Unit Representative
  • CISO
  • Institutional Incident Response team
  • Privacy Officer
  • Others on a need-to-know basis
If requested by IT Security Officer, CIO, or another administrator

(Ad-hoc emails informing progress and/or formal incident report or lessons learned report)

Low As soon as practicable

(No more than one business day)

Incident Response Lead
  • Unit Representative
  • Others on a need-to-know basis
(Ad-hoc emails informing progress)

*It refers to the time it would take for the incident response team to respond to incidents.

Role equivalency table (institutional x units)

Role Institutional teams Divisional (unit) teams
Information Security Officer
  • Associate Director, Information Security Operations
  • Division, Information Security Lead
  • Division, IT Manager
  • Division, IT Leader or delegate
Incident Response Lead
  • Incident Response Architect
  • Security Analyst
  • Division, Information Security Lead
  • Division, IT Manager
  • Division, IT Leader or delegate
IT Administrator N/A
  • Division, IT Director
  • Division, IT Manager
  • Division, IT Leader or delegate
Unit Administrator N/A
  • Division, CAO
  • Division, Dean, Associate Dean

Division, Business Manager or delegate

Unit Representative N/A
  • Division, Business Manager or delegate
  • CIO or delegate
  • CIO or delegate
Institutional Incident Response Team
  • Institutional Incident Response Team
Privacy Officer
  • FIPPA Office
  • FOIL (Freedom of Information Liaison)
Others on a need-to-know basis
  • Institutional IT teams’ representatives
  • Any other relevant person to inform or resolve the incident.
  • Other IT teams’ representatives
  • Any other relevant person to inform or resolve the incident.

Common incident types

The Incident Response program’s primary objective is to mitigate and contain the risk associated with computer security incidents. Some of the most common types of incidents are:

  • Phishing attacks,
  • Malware and viruses,
  • Denial of resources or services,
  • Unauthorized access or attempts to gain unauthorized access,
  • Inappropriate use of network resources,
  • Ransomware
  • Data breaches
  • Changes to system hardware, firmware or software without owner’s knowledge,
  • Any other unlawful activity involving computer networks and processing equipment.


Following the list of common incident types, playbooks are generally created to handle security incidents systematically and consistently. Incident response teams should leverage “Playbooks” as much as possible.  Some examples are provided below:

UTM – Ransomware playbook

Training, awareness & annual assessment

General security incident response training, awareness and practices that shall be followed by Units:

  • Review and adopt the Incident Response Plan (this document) or use it to create your own plans.
  • Familiarize with the methodologies associated with the incident response process, including incident containment and playbooks.
  • Review plans once a year and train team members as appropriate for operational readiness.
  • Submit incident response plans to be incorporated in the DAI-IRSA annual assessment process.

Incident Response Handling (Practical Guide)

  1. Review checklists and toolkits
  2. CSIRT
  3. Communication Plan
  4. Incident Reporting
  5. Tabletop Exercises

In addition to documenting procedures, units shall provide training and awareness to  staff and faculty to recognize and report incidents as quickly as possible.

Reporting an incident

When reporting an incident to information Security, follow the procedure detailed on the page linked below:

IRP Main Web Page

Additional external resources

External resources may be required depending on the severity of the incident and the data types or assets involved. The engagement of those resources would typically incur additional costs to the Unit.   These may include:

Breach Coach

A Breach Coach is functionally a project manager for an incident.  For significantly extensive or severe incidents, the services of a Breach Coach may be needed. In addition to project incident management services, they can also arrange access to the other resources listed below.

In many cases, the breach coach role can be subsumed by sufficiently expert external counsel, who can offer breach coaching services/functions as part of their legal advice and guidance.