Incident Severity Levels. During the term of this Contract, Contractor will provide the services necessary to remedy any Severity Xxxxx 0, Xxxxxxxx Xxxxx 0 or major impact Severity Level 3 incidents in the Solution and to acknowledge, evaluate and record any other incidents in the Solution. Fixes for Xxxxxxxx Xxxxx 0 and Severity Level 4 incidents will be prioritized after all Xxxxxxxx Xxxxx 0 and Severity Level 2 incidents are remedied. Support Services will commence promptly after the State has identified an incident with the Solution and has notified Contractor’s support desk of the incident. During the Support Term, the State will have access to a Contractor support desk twenty-four
Incident Severity Levels. There are three severity levels for incidents. Refer to section 7.c. below for service availability hours. Incident reports sent to the Help Desk outside of the regular hours are referred to as after-hours reports. CRITICAL • The web application does not respond to user requests • Data is corrupt • System security has been compromised The Help Desk shall acknowledge receipt of a Critical incident within one hour during regular hours and within twelve hours during after-hours support. HIGH • Productivity or work stoppage may occur or be significantly impaired but website is working • The incident may cause a security problem if not resolved quickly • Private information may be disclosed if the incident is not resolved quickly The Help Desk shall acknowledge receipt of a High incident within two hours during regular hours, but shall not respond to an after-hours, high incident report.
Incident Severity Levels. 5.1. Severity 1
Incident Severity Levels. If Mercury and Global do not agree on the severity level at time of incident, the higher severity level will determine the Response and Restore time defaults detailed in Table 2. After the service is restored, Mercury will, in good faith, consider all information provided by Global and make a final determination of the severity level. • Global will generate a single response for each trouble ticket that is received from Mercury to confirm receipt of the incident notice.
Incident Severity Levels. 2.1. Severity Level Definitions for the needs of determining Things Solver response time frames Incident Severity Level Description of consequences suffered by Software Solution users CRITICAL Critical impact on business An error in the application module results in the imminent threat to the key business or near-term business milestone that pose a financial risk to the Customer. There is no backup solution to a specific problem (i.e. the job cannot be done in any other way). HIGH High impact on business An error in the application module prevents a part of the Customer’s work from being performed on a process level, with a small financial and/or business risk. There is a backup solution with a workaround, or non-key processes are impacted with no workaround. LOW Minor impact on business An error in the application module has a non-key business impact with a workaround or no business impact. The error does not prevent the User from performing most of his tasks without interruption. There is a backup solution to overcoming a specific problem. An error in the application module carries minimal or no business/financial risk. An error in the application module is classified as an acceptable risk exposure at the process level, with minor operational corrections. In terms of support for the services specified in this Agreement, Things Solver will respond to Service Requests related to the Software submitted by the User within the following time frames: Severity level Time to first response Time to resolution CRITICAL 1 day 5 working days HIGH 2 days 7 working days LOW 5 days 10 working days The time defined in the table above is the Working Time of Things Solver, which means working hours and working days in accordance with the CET time zone and the laws of the Republic of Serbia. Travel time (if applicable) is not included in the periods listed in the table above.