Attachment B - IPP.pdf

PDF 276 KB Posted

Attached to
SYNOPSIS ONLY - Litigation Support Services
Solicitation number
2031JW25N00003
Issued by

About this file

This document is a Request for Proposal (RFP) Performance Work Statement Attachment B for an Incident Priority Process Standard Operating Procedure. It defines the methodology for determining the priority of IT incidents within the Office of the Comptroller of the Currency (OCC) computing environment. The process involves evaluating the impact and urgency of incidents to assign one of four priority levels: critical, high, medium, or low. The document provides detailed definitions and tables for assessing impact (0-4) and urgency (0-3), as well as a priority matrix for determining the final priority based on these two factors. The goal is to ensure a standardized and consistent process for prioritizing incident resolution across all OCC IT support groups.

The related federal contract opportunity is for Litigation Support Services, where the OCC is seeking to establish a single-award contract to provide expertise in eDiscovery tools and services to support legal matters such as subpoenas, investigations, and civil litigation. The OCC plans to issue a solicitation for this requirement between October and November 2024, with a 5-year ordering period inclusive of four 12-month option periods. The Government intends this to be a full and open competition with no set-aside.

View the file

Other files

File Type Posted
DRAFT--PWS_v.2.2_LSS 2025.docx DOCX document
Attachment D - QASP.docx DOCX document
Attachment F - PSP-F.xlsx XLSX spreadsheet
Attachment C - CODRD.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Request for Proposal (RFP): 2031JW21R00006

Performance Work Statement Attachment B

Incident Priority Process-Definition

Standard Operating Procedure

The Incident Management Priority matrix describes the method all ITS support groups will use to determine the priority of IT incidents within the OCC computing environment. This documentation includes the practical application of decision factors that will properly classify the incidents priority.

Incidents need to be properly prioritized to ensure they are resolved in the order of importance.

Contents I. Scope

II. Incident Priority Definition

B. Impact

C. Urgency

D. Priority

III. Summary

Figure 1: Key Participants Figure 2: Impact Table Figure 3: Urgency Table Figure 4: Priority Table Figure 5: Priority Matrix

Figure 1: Key Participants

Key Participants

ITS Support Groups ITS Queue Managers ITS Managers/Supervisors

All ITS Technicians & Agents ITS Enterprise Service Desk

I. Scope

Incident priority matrix defined by this documentation applies to all IT incidents created within OCC.

II. Incident Priority Definition

Incident Priority is determined by using a two-factor method that computes impact of the incident as well as the urgency, to determine priority. This method allows for a more systematic approach to prioritization and ensures that the standardization of priority provides for a more timely and effective rate of resolution.

4- step process accomplishes this two-factor methodology to incident prioritization:

1. Thoroughly evaluate the incident in question.

2. Give the incident a numerical value (0-4) based on the impact of the incident.

3. Give the incident a numerical value (0-3) based on the urgency of the incident.

4. Using both values above, navigate to the priority table to determine priority that is defined by determining where the impact value and the urgency value intersect.

B. Impact

The crux of this four-step process is the implementation and understanding of the two factors, Impact and Urgency. Impact rating is determined by assessing how widespread the incident is affecting IT/business operations. Higher impact rating is given to incidents that are a direct causation of catastrophic events, natural disasters, and/or man-made disasters while lower ratings are given to incidents that may inconvenience a single user across the entire agency.

Special emphasis is given to VIP’s in the organization as well as services that may have a negative cascading effect. The special emphasis given to the services that may have cascading effects is due largely in part because if that IT service is suffering from an incident it may have an effect on other potentially dependent systems that can quickly deteriorate the operational viability of the organization. This same emphasis is given to high priority systems that may not have a cascading effect but are deemed critical to the operations of the agency as a whole. The impact chart below depicts all the impact ratings as well as a brief definition of impact and some examples to assist in guiding the selection of a rating.

Figure 2: Impact Table

Impact Description

Catastrophic Event, Natural Disaster, Man-Made Disasters, etc.(i.e. Hurricanes, Earthquakes, Terrorist Attack, other designated Disaster Recovery Situation etc.)

Whole organization is affected, OCC External Applications are not available, Services that could have a cascading effect on other services or systems

• Priority 1 and 2 Services and Applications

VIP or equivalent designate, District Offices or complete Business unit impacted

• Priority 3 Services and Applications

Large groups, Complete/Multiple offices are affected [Non-Core Applications, Applications or Services in the Development environment are affected]

• Priority 4 Services and Applications

Single user is affected, small group within one office (i.e. generally less than 10 users)

C. Urgency

The secondary factor is Urgency. Urgency is the level at which the end-user(s)’s business process or productivity has been affected or can potentially be affected. A scale of 0-3 is used to assign urgency to an incident; the lower the urgency rating the less the end-user(s) is able function properly or the more their business processes have been affected. Unlike the impact variable that is assigned by the IT professional assessing the incident, urgency is a value that is provided by the end-user. Only the end-user is able to properly determine how much the incident is affecting their business process and/or productivity levels. The chart below depicts all the urgency levels, and a brief description of each.

Figure 3: Urgency Table

Urgency Description

Catastrophic: Business processes have stopped; user(s) are not able to do any work

High: Business processes are affected with no temporary workarounds in place; some features/capabilities are not functioning

Medium: Business processes are affected but temporary workarounds are in place; some features/capabilities are not functioning

Low: Business processes are not affected, temporary workarounds may or may not be implemented

D. Priority

Priority classification is done through the implementation of four levels of priority. In the case where there are numerous pending incidents with the same priority classification, priority will be based on date of incident submission. The priority level terms are described in chart below.

Figure 4: Priority Table

Priority Level Terms

1. Critical

2. High

3. Medium

4. Low

Once the impact and urgency ratings are determined by adhering to the points above, priority is determined by finding the intersection of both values on priority Matrix below.

Figure 5: Priority Matrix

IMPACT

0 1 2 3 4

Critical Critical

Critical Critical

High High Medium

U R

G

EN

C Y

High Medium Medium

High High Medium

Medium

Low Low

Low Low High Medium

III. Summary

This Incident Management Priority documentation clearly identifies the factors that play a role in the definition of priority and is intended to ensure that all IT Support groups throughout OCC standardize on a process to classify an incident and assign it a priority. This will ensure that incidents assigned to various IT Support Groups, will be worked on in the order of importance consistently throughout the lifecycle of the incident.

There will be no deviations under any circumstance from this priority matrix when classifying priorities for incidents. Should extenuating circumstances arise and a deviation is required, it should be accomplished through a subsequent revision of this documentation but not by any specific exception given to any IT Support Group.

File details come from the government source that posted it. Updated .