Exhibit 1 SOW Att 1.2 Service Level Definitions_Final.docx

RFO DIR-CPO-STS-602

State of Texas

Department of Information Resources

Attachment 1.2

Service Level Definitions

Managed Network Services (MNS)

DIR-CPO-STS-609

Version 1.0

State of Texas Department of Information Resources, Shared Technology Services Managed Network Services (MNS) – Attachment 1.2 Service Level Definitions Page 2 of 2

RFO DIR-CPO-STS-602

Critical Service Levels This Section sets forth qualitative descriptions of the Critical Service Levels, as well as the required service levels, collection and reporting timing and algorithm for calculating attainment.

NOTE: All days are calendar days unless otherwise noted.

SR infrastructure - Service Availability

SERVICE LEVEL NAME

SR infrastructure Service Availability

SR infrastructure Service Availability means access to the production system is enabled; log-in permitted from the local user area network and business transactions can be executed, and all requisite services for lifecycle management are available. The expectation is that the Successful Respondent will implement operational processes, instrumentation, monitoring, and controls that validate availability of the Services.

Available minutes = the total number of minutes in a month (24 hours x number of days in the month X 60 minutes) for each Service.

Unscheduled downtime = the total number of Available minutes in which a Service is not Available for reasons outside of metric exclusions and solely due to the fault of the Successful Respondent.

The SCP will improve the Incident ticket quality, including Unavailability records and accurate Start Time, via Root Cause analysis for Severity 1 and 2 Incidents, and the use of tools if such tool data is Available.

For reporting purposes, required data elements will be collected from each of the data sources. For example:

MSI ITSM – incident ticket number, incident summary, incident resolution text, resolution time, impacted CI name(s), actual outage start time, actual outage stop time, and outage duration MSI CMDB – Application instances and related Cis supporting impacted Application Service Management Manual – maintenance schedules, hours of operation Collected data will be sourced by the MSI’s SLA tracking Application for purposes of aggregating, calculating, measuring, and reporting SLA results. Manual input will be considered for purposes of supplementing collected data where necessary.

REPORTING TOOLS

MSI service management system MSI Service Level management reporting system

RAW DATA STORAGE (ARCHIVES)

Data used to calculate the SR infrastructure Service Availability result for reporting will be stored in the MSI Service Level management Reporting system database, which will be accessible to users via report drill-down functionality for a rolling 13 months. An additional 23 months of data will be archived and made Available via the MSI Service Level management reporting system upon request by DIR.

Customer Infrastructure Availability

SERVICE LEVEL NAME

Customer infrastructure Availability

Service Availability means access to the production system is enabled; log-in permitted from the local user area network and business transactions can be executed, and all requisite services for lifecycle management are available. The expectation is that the Successful Respondent will implement operational processes, instrumentation, monitoring, and controls that validate availability of the Services

All pre-defined exclusions by the Successful Respondent prior to the commencement of services. For clarity, pre-defined exclusion are for configuration of equipment that does not meet SLA, Support contracts do not support SLA. It is incumbent on the Successful Respondent to identify circumstances where the network environment will not meet the SLA requirements.

Available minutes = the total number of minutes in a month (24 hours x number of days in the month X 60 minutes) for each Service.

Unscheduled downtime = the total number of Available minutes in which a Service is not Available for reasons outside of metric exclusions and solely due to the fault of the Successful Respondent.

The SCP will improve the Incident ticket quality, including Unavailability records and accurate Start Time, via Root Cause analysis for Severity 1 and 2 Incidents, and the use of tools if such tool Data is Available.

For reporting purposes, required Data elements will be collected from each of the Data sources. For example:

MSI ITSM – incident ticket number, incident summary, incident resolution text, resolution time, impacted CI name(s), actual outage start time, actual outage stop time, and outage duration MSI CMDB – Application instances and related Cis supporting impacted Application Service Management Manual – maintenance schedules, hours of operation Collected Data will be sourced by the MSI’s SLA tracking Application for purposes of aggregating, calculating, measuring, and reporting SLA results. Manual input will be considered for purposes of supplementing collected Data where necessary.

MSI service management system MSI Service Level management reporting system

RAW DATA STORAGE (ARCHIVES)

Data used to calculate the Service Availability result for reporting will be stored in the MSI Service Level management Reporting system database, which will be accessible to users via report drill- down functionality for a rolling 13 months. An additional 23 months of Data will be archived and made Available via the MSI Service Level management Reporting system upon request by DIR.

All Services - Incident Resolution Time – (Severity 1 - 4)

SERVICE LEVEL NAME

All Services - Incident Resolution Time – (Severity 1 - 4)

If an infrastructure Incident is escalated to a higher Severity Level, then the Resolution Time clock restarts upon escalation to the higher Severity Level. Upon escalation, a new ticket will be created, and the original ticket will be cancelled. The cancelled ticket will be related to the new ticket.

Severity 1 Incidents:

< 2 hours Severity 2 Incidents:

< 3 hours Severity 3 The infrastructure Incident shall be Resolved within 3 Business Days) where such minutes shall be measured only between 8:00 AM and 5:00 PM inclusive on Business Days.

Severity 4 The Infrastructure Incident shall be Resolved within 7 Business Days) where such minutes shall be measured only between 8:00 AM and 5:00 PM inclusive on Business Days.

For purposes of clarity, note the following:

If an infrastructure Incident is opened within the current Measurement Window, but its relevant resolution timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Incident is actually Resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation) An open infrastructure Incident that has exceeded the relevant resolution timeframe is also carried forward into subsequent Measurement Windows as a breach until Resolved; if it is resolved within twenty-eight (28) days following its relevant resolution timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the resolution timeframes in each subsequent Measurement Window’s calculation until Resolved.

Incident data will be loaded to MSI Service Level management reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI Service Level management reporting system

Root Cause Analysis (RCA) Delivery

SERVICE LEVEL NAME

Root Cause Analysis (RCA) Delivery

Successful Respondent will provide Root Cause Analyses for all Severity 1 Incidents and as requested by DIR and/or DIR Customer.

Information Technology Service Management (ITSM) System

· Problem investigations for Root Cause Analyses will be logged and tracked in the MSI ITSM. Problems will be categorized and assigned to teams who will analyze the Problem, perform, and document the Root Cause analysis. The Problem record will be completed and progressed through the Problem Management lifecycle.

· Problem data will be loaded to MSI Service Level management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

· MSI ITSM

· MSI Service Level management reporting system

RCA Corrective Action Implementation

SERVICE LEVEL NAME

RCA Corrective Action Implementation

Information Technology Service Management (ITSM) System

Corrective actions will be logged and tracked in the MSI ITSM. Corrective actions will be assigned to teams who will implement the corrective actions. The corrective actions will be progressed through the Problem Management lifecycle.

Problem data will be loaded to MSI Service Level management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI Service Level management reporting system

Change Management Effectiveness

SERVICE LEVEL NAME

Change Management Effectiveness

Changes are not successfully implemented if they:

do not comply with the Change Management procedures (including the Change Control Process), the SMM and, except as specified in clause

1. to this sentence, any associated project plan,

2. cause either a Severity 1 Incident or Severity 2 Incident,

3. exceeded the change window,

4. are backed out, or

5. partial success of change is backed out or unsuccessful.

Change data will be loaded to MSI Service Level management reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI Service Level management reporting system

SR Infrastructure Patch Compliance

SERVICE LEVEL NAME

SR Infrastructure Patch Compliance

ITSLM Reporting Application (MSI Service Level Management Reporting system)

Excused events approved by DIR through the SLA Exception procedure documented in the SMM.

The change will document, categorize, and be assigned to implementer teams who will work to plan, review, obtain approvals, and progress the ticket through the change management lifecycle. If the patch is approved by the DIR Customer and CAB (Change Advisory Board), SCP will follow the Change Management Process to schedule the patch installation. If the change is rejected by customer, it will not be measured in the SLA.

SLA is measured upon timely submission of the change, from the date the patch is available by manufacture (patch release date/time by manufacturer) to when the change is created (create date) \ and the patch being applied successfully (change closed as successful).

MSI Service Level management reporting system

SR Infrastructure - Vulnerability Management

SERVICE LEVEL NAME

SR infrastructure Vulnerability Management

METRIC INCLUSIONS and DATA SOURCES

1. Vulnerability Detection and Reporting:

a. All identified or assigned network vulnerabilities that require evaluation for risk impact, including

2. Assignment and Notification:

a. Documentation showing the assignment of each assessed vulnerability to the appropriate MNS entity responsible for remediation Confirmation of acknowledgment by responsible MNS parties, including timestamped records that indicate when the vulnerability was assigned and communicated for action.

3. Applicable Vulnerability Management Events within the Measurement Window:

a. Only vulnerabilities identified within the defined measurement period (e.g., daily, weekly, monthly) as per the SLA are included.

4. Tracking and Escalation:

a. Any escalations related to unassigned or delayed vulnerabilities within the assessment and assignment process Data Sources

1. Vulnerability Management System (VMS)

2. Incident Management or ticketing system

3. Threat Intelligence and scanning tools

4. SOC assignment reports

1. Logs from the VMS showing vulnerability detection, assessment timestamps, and assignment actions. Vulnerabilities discovered through automated scanning tools, manual assessments, or third-party threat intelligence ingested into the Vulnerability module

2. Service Now ticket records showing each vulnerability’s assignment to the appropriate entity, along with timestamps indicating when assignment notifications were sent

3. Records from vulnerability scanning tools and threat intelligence feeds that provide initial detection timestamps for vulnerabilities.

4. Reports on any identified vulnerabilities, their details, and risk scores provided by external or third-party tools.

5. SOC-generated reports that track and escalate vulnerabilities that are not assigned within the SLA timeframe.

6. Documentation of vulnerabilities requiring special handling, additional information, or coordination with external entities.

· MSI vulnerability response system

· MSI Service Level management reporting system

Solution Proposal Delivery

SERVICE LEVEL NAME

Solution Proposal Delivery

Following validation of requirements by Successful Respondent, the Successful Respondent shall deliver a proposal for each request within the time frames listed below based on solution complexity:

Low – within 10 Business Days Medium – within 15 Business Days High – within 23 Business Days Custom – within 35 Business Days When a proposal is delivered, it must include a committed timeframe for project implementation specified as Business Days from the time the project is assigned to the project pool to the implementation completion. This committed number of Business Days will be used in the “Solution Implementation” Service Level.

Specific size criteria and guidelines shall be maintained in the SMM.

For purposes of clarity, note the following:

1. If a solution proposal request is opened within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such request is actually delivered in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation) An open solution proposal request that has exceeded the committed timeframe is also carried forward into subsequent Measurement Windows as a breach until delivered; if it is delivered within twenty-eight (28) days following its relevant committed timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until delivered.

Solution proposal data will be uploaded to MSI service management system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI service management system MSI Service Level management reporting system

Solution Implementation

SERVICE LEVEL NAME

Solution Implementation

Projects will be reported in the Measurement Window in which the associated Project (PPM) ticket is closed, allowing sufficient time to determine if the project was successful.

For purposes of clarity, note the following:

1. If a project is assigned within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such project is actually implemented in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation)

2. An uncompleted project is also carried forward into subsequent Measurement Windows as a breach until implemented; if it is implemented within twenty-eight (28) days following its relevant committed timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until implemented.

Solution implementation data will be loaded to MSI Service Level management reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI service management system MSI Service Level management reporting system

Key Service Levels This Section sets forth qualitative descriptions of the Critical Service Levels, as well as the required Service levels, collection and reporting timing and algorithm for calculating attainment.

NOTE: All days are calendar days unless otherwise noted.

Invoice Dispute Resolution

SERVICE LEVEL NAME

Invoice Dispute Resolution

For purposes of clarity, note the following:

if an Invoice dispute is initiated within the current Measurement Window, but the twenty Business Days extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such dispute is actually resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation) an open Invoice dispute that has exceeded the committed timeframe is also carried forward into subsequent Measurement Windows as a breach until resolved; if it is completed within twenty-eight (28) days following its relevant committed timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until completed.

Invoice Dispute Data will be loaded to MSI Service Level management reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

MSI service management system MSI Service Level management reporting system

Data Quality

SERVICE LEVEL NAME

Data Quality

“Key processes” mean those processes that are foundational to the delivery of Services (e.g., Major Incident Management, Refresh), as defined in the SMM.

“Critical attributes” mean the attributes associated with the Configuration Items for which quality data is necessary to successfully operate the key processes (e.g. operating System, operating System version), as defined in the SMM.

“Business rules” mean the set of checks that will be performed to on an attribute to determine quality, as defined in the SMM.

Data Quality business rules will be run against the selected attributes on a regular basis within the Measurement Window. Data Quality output will be loaded into the Digital MSI Service Level Reporting System on a regular basis within the Measurement Window, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Chronic Incidents: Recurrence Rate

SERVICE LEVEL NAME

Chronic Incidents Recurrence Rate

Excused events approved by DIR through the SLA Exception procedure documented in the SMM.

· MSI Service Level management reporting system

SR Infrastructure Vulnerability Resolution

SERVICE LEVEL NAME

SR Infrastructure Vulnerability Resolution

The “SR infrastructure Vulnerability Resolution” SLA measures Network Vulnerability items for which measurement begins when the vulnerable item State is set to “Open”, ends when the vulnerable item is set to “Closed Complete”, no Pause duration is considered in this SLA calculation For clarity, resolution of the Network Vulnerability item is defined when the configured item has been patched, reconfigured or a deferral has been approved.

A deferral will only be approved to allow for a 90 day time period and is meant to allow the SCP or customer time to schedule the remediation effort. If the vulnerability management group grants a deferral and the remediation effort of the vulnerability is not completed in the deferral window the vulnerability will be counted as not resolved within the defined timeframe.

Reports will be measured when the vulnerable item Closed Date is in the reporting period.

Providers follow standard change management processes and procedures as documented in the SMM Timeframes to complete the notification will be based on the documented scores in the SMM, as depicted below.

Critical/High 30 days Medium – 60 Days Low – 90 Days Vulnerable items automatically created based on positively identified scanned results will be logged in the MSI ITSM system, which may be identified by:

· Automated outputs of the Security Module (Automated Vulnerable Items)

· MSBC results

· SCP Audit results

· Annual 3rd party Assessment results

· Manual vulnerability request

· Emergency Vulnerability Management Group (EVGM) Committee

Cancelled Requests

For purposes of clarity, note the following:

1. If a Network Vulnerability item is opened within the current Measurement Window, but its relevant SMM resolution extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Network vulnerability item is actually resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation) An open Network Vulnerability item that has exceeded the SMM resolution timeframe is also carried forward into subsequent Measurement Windows as a breach until resolved; if it is resolved within SMM defined timeframes following its relevant resolution timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until resolved.

Security vulnerability item data will be loaded to Digital MSI Service Level Management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria

ServiceNow Service Level Targets (Digital MSI Service Management system) ITSLM Reporting Application (Digital MSI Service Level Management reporting system)

Service Request Fulfillment

SERVICE LEVEL NAME

Service Request Fulfillment

Specific target timeframes are maintained in the SMM.

For purposes of clarity, note the following:

1. If a Service Request is opened within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Service Request is actually resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation) An open Service Request that has exceeded the committed timeframe is also carried forward into subsequent Measurement Windows as a breach until resolved; if it is resolved within twenty- eight (28) days following its relevant resolution timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until resolved.

Service Request data is automated and will be ingested to MSI Reporting tool on a daily basis. MSI Tool will filter Service Request tickets based on appropriate measurement criteria.

MSI service management system MSI Service Level management reporting system

Network Dispatch

SERVICE LEVEL NAME

Network Dispatch

The “Network Dispatch” SLA measures Network Dispatch tickets for which measurement begins when the Network Dispatch state is set to “open”, and ends when the Network Dispatch is set to “closed complete”, The following timeframes will be used to calculate the Network Dispatch SLA:

Metro = <4 Hours Urban = <6 Hours Rural = <8 hours Pause conditions will be allowed, when

1. Technicians are awaiting parts from the Customer or Customer vendor

2. Waiting on Customer Access to Network Environment

Cancelled Requests