SLA Template

SERVICE LEVEL AGREEMENT

Service Provider(s)

[ Type Department Name ], ITU

Requesting Organization(s)

[ Type Department Name ]

Service Title

[ Type Service Name* ]

Document Owner

[ Type Owner Name ]

Effective Date

[ Type Date], Version [#]

Review Date

[ Type Date]

Physical Document Location

[Type location]

Online document Location

[ Type URL of Online Copy ]

* Must use IT Services Catalog titles when available (http://itservices.gmu.edu)

VERSION HISTORY

Version No.

Date

Revised By

Reason for Change

APPROVAL SIGNATURES By signing below, I agree to the terms of this Service Level Agreement (SLA) and that these terms will take effect the date approved and signed by all required parties. I acknowledge that the performance period of this agreement is twelve months and may be extended only upon review and re-approval by all approving parties. I also agree that I have read and complied with the Data Stewardship Policy 1114 and am aware that an immediate revision of the SLA is required if any changes to data sets covered by this agreement occur during its performance period. I agree to review potential data set changes with the IT Security Office and notify key stakeholders of proposed changes, including the Service Provider, so that this SLA can be revised prior to implementing any data set modifications.

Representative, Service Provider

Phone: Email:

Date

Representative, Requesting OrganizationPhone:

Email:

Date

Data Steward, Requesting OrganizationPhone:

Email:

Date

Review:

Executive DirectorPhone:

Email:

Date

SERVICE LEVEL AGREEMENTTABLE OF CONTENTS

1.Service Description1

2.Service Level Performance2

3.Roles and Responsibilities3

3.1Service Provider Stakeholders3

3.2Service Provider Responsibilities3

3.3Service Dependencies & Underpinning Contracts3

3.4Requesting Organization Stakeholders4

3.5Requesting Organization Responsibilities4

4.Methods of Requesting Service4

5.Hours of Coverage, Response Times and Escalation5

5.1Hours of Coverage5

5.2Incidents5

5.3Escalation Process6

5.4Service Requests6

6.Maintenance and Service Changes6

7.Pricing7

8.Service Review & Reporting8

9.Data Stewardship & Security8

Appendix A: Required Policies, Processes and Procedures10

Appendix B: IT Support Centers Urgency Table11

DRAFT TEMPLATE

DRAFT TEMPLATE

DRAFT TEMPLATE

SERVICE LEVEL AGREEMENT

This Service Level Agreement (SLA) between the Service Provider(s) and Requesting Organization(s) documents the working relationships required to support the requested service identified below. This SLA will be reviewed on an annual basis and remain valid until an associated dataset is modified or the agreement is revised or terminated. Either party may amend or terminate this agreement through written notification and pending approval of all stakeholders.

Service Provider(s)

[ Type Department Name ], ITU

Requesting Organization(s)

[ Type Department Name ]

Service Title

[ Type Service Name ]

Service Description

This section describes the service being requested, the resources to be provided by the ITU, any user requirements, and important service support boundaries.

Description

[Type text]Insert description from the IT Services Catalog if available (http://itservices.gmu.edu)

Features

[Type text]List service features, such as those related to design, development, hosting, and implementation.

Optional Features

The Requesting Organization(s) has the option to request [Insert Services] to be provided by [Insert Provider] at an additional cost. The Requesting Organization(s) will indicate their intent to exercise this option by circling either Yes or No in the column to the right.

Yes / No

Resources Provided by Service Provider

[ Type text ]List significant infrastructure, people, and processes that will be provided, such as (a) escalated support services, (b) system operations, administration, and network connections, (c) web access, (d) system level backup processes, and/or (e) disaster recovery

User Requirements

[ Type text ]Example: Software Requirements (PHP-5.3, Apache Web Server-2); System Access Requirements (Shell Access via SSH; My SQL privileges, file level privileges to view log files)

Service Boundaries

[ Type text ]List any relevant systems, services and features not included in this agreement

Service Level Performance

This section details how the Service Provider(s) will monitor or track and report on service performance. The table below provides a list of the metrics and target performance levels to be reported on along with the format and interval of the reporting.

Metric*

Target Performance Level (TPL)

Format

Interval

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

The Service Provider(s) will not report on the following service levels or metrics:

[Type text]

* To complete this section, identify important metricse.g., Key Performance Indicatorsthat can be measured on a regular basis. Balance the importance of a desired metric against its ease of collection. Avoid including an excessive number of metrics or metrics that cannot be analyzed in a timely manner. Find example metrics online at ITIL Key Performance Indicators or the Service Metric Template. Frequently used metrics include Response Time, Throughput, Customer Support, Availability, and Utilization. Examples provided below.

Metric: Response TimeTPL: 95% of users will experience a response time of two seconds or less during regular working hours of 7:30 to 5:00Format: ReportInterval: Weekly

Metric: AvailabilityTPL: The application will be available 98% of the time, 7 days a week, 19 hours per dayFormat: Listerv NotificationInterval: Monitored Daily

Roles and Responsibilities

This section documents the roles and responsibilities of the Service Provider(s) and Requesting Organization(s). It also identifies all primary stakeholders associated with this Service Level Agreement.

Service Provider Stakeholders

The Service Provider(s) Stakeholders associated with this SLA are listed below along with their respective Title/Role and departmental contact information (versus reach numbers of specific persons). Service Provider responsibilities are addressed in Section 3.2.

Stakeholder

Title/Role

Contact Information

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

Service Provider Responsibilities

The Service Provider(s) agrees to provide the infrastructure, technology, people, processes and monitoring tools necessary to support the service requested. In addition, the Provider agrees to the following responsibilities:

[List responsibilities here as related to each provider identified in 3.1.]

Example Responsibilities:

Clearly document services provided in ITU Support Center Service Catalog, if available

Meet response times associated with the priority assigned to incidents and service requests

Generate quarterly reports on service level performance

Provide appropriate notification to customers and Stakeholders for all scheduled maintenance via the ITU Maintenance Calendar, the Alerts and Outages web page, or another agreed upon communication

Service Dependencies & Underpinning Contracts

Certain services may be relied upon to ensure the service requested in this SLA functions as documented. Such service dependencies are listed below with links to their respective Operational Level Agreements if available. (If an OLA does not exist, the Service Provider(s) identified with the dependent service will serve as a primary contact.)

Service*

Description

Unit

OLA Exist?

OLA Link

[Type text]

[Type text]

[Type text]

[Yes/No]

[Type URL]

[Type text]

[Type text]

[Type text]

[Yes/No]

[Type URL]

[Type text]

[Type text]

[Type text]

[Yes/No]

[Type URL]

[Type text]

[Type text]

[Type text]

[Yes/No]

[Type URL]

[Type text]

[Type text]

[Type text]

[Yes/No]

[Type URL]

* To complete this section, identify and briefly describe important and relevant service dependencies. Note whether an OLA exists for each service and provide a URL for any existing OLAs. Examples of service dependencies include network availability, backups, data center hosting, reporting, and vendor support.

Requesting Organization Stakeholders

The Requesting Organization(s) Stakeholders associated with this SLA are listed below along with their respective Title/Role and departmental contact information (versus reach numbers of specific persons). Requesting Organization(s) Stakeholder responsibilities are addressed in Section 3.5.

Stakeholder

Title/Role

Contact Information

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

[Type text]

Requesting Organization Responsibilities

The Requesting Organization(s) is considered to be the Data Owner and is responsible for all data sets within their purview that are covered in this agreement. This data may be Sensitive, Protected or Public Data as defined by Policy 1114, Data Stewardship (refer to Section 9 of this document). In addition, the Requesting Organization(s) agrees to the responsibilities listed below:

[List relevant responsibilities here for the Requesting Organization(s)]

Example responsibilities may include policy implications or tasks, utilizing the ITU Support Center for incidents, or contacting the IT Service Manager for additions or changes in established service levels.

Methods of Requesting Service

This section identifies the various methods by which the Requesting Organization(s) may request service or support:

[List specific methods here]

Example methods may include the following:

Online via Service Desk Express (SDE)

Phone via ITU Support Center (703-993-8870)

Email (support@gmu.edu)

Walk-in (ITU Support Center)

Negotiation with Service Provider

Hours of Coverage, Response Times and Escalation

This section describes the particular hours of coverage, the response times, incidents, and the escalation processes for this service. For all requests, the ITUs goal is to have a staff member assigned to the service and acknowledging service requests within eight (8) business hours of receipt. Campus priorities may require exceptions to this goal.

Hours of Coverage

Hours of Coverage

[State specific hours of coverage]

Example: This service is provided (enter number) hours a day (enter number) days a week except for periods of planned maintenance.

Exceptions

[ List any exceptions to service coverage]

Example: This service may be temporarily unavailable during the planned maintenance period on Sundays. Refer to Section 6 for additional information.

Incidents

An incident is defined as an unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. The IT Support Center categorizes incidents based on urgency type: Urgent, Standard, Scheduled (see Appendix B).

Prioritization

[ Describe the method to prioritize incidents. List any exceptions to this prioritization.]

Support Hours

[Describe the number of business hours of support, the number of after hours of support, and how the Service Provider manages them]

Response Time

[Describe the Service Providers response times per type of incidenturgent, standard, or scheduledand both during and after business hours. List any exceptions to this response time.]

Reporting

[ State how incidents will be reported to the Requesting Organization and/or key Stakeholders]

Escalation Process

Escalation

[ Define the escalation process if the Service Provider is not meeting expectations]

Exceptions

[ List any exceptions to this process]

Service Requests

This section describes methods that should be used by the Requesting Organization(s) to make inquiries about or modifications to the service covered in this SLA. It also documents response times agreed to by the Service Provider(s).

General Information Inquiry

[Describe methods for the customer to request and receive answers to questions and information from the Service Provider]

Service Modification Inquiry

[Describe how the customer should request modifications to the service, its features or functions.]Example: Submit requests for changes in service features, functions , or other service modifications to .

Response Method

[ Identify process by which the Service Provider will respond to requests]

Response Time

[ Identify response turnaround time. List any exceptions]

Maintenance and Service Changes

This section describes when this service is subject to maintenance and how the Service Provider(s) will communicate service changes.

Maintenance

Is the maintenance window for this service consistent with the one described in Section 6? Yes / No If No, describe the differences in the field below.

Alternate Maintenance Window

[ Describe how the maintenance window for this service differs from the standard window described here in Section 6.]

A maintenance window is a defined period of time during which planned outages and changes to production services and systems may occur. (A production service or system is used by university members to complete business or academic tasks and objectives.) The purpose of specifying standard maintenance windows is to allow clients of the service to prepare for possible disruption or changes. The ITU uses the following standard maintenance window:

Planned outages are generally scheduled and performed between 7:00 A.M. and 11:00 A.M. on Sundays. Commonly, work scheduled outside of this window has explicit sign-off from the client representative.

Planned outages and changes are not scheduled during significant events or key dates, if known. This includes two weeks prior to the start of each academic quarter, the first week of classes, finals week, and grading week.

The Service Provider(s) will schedule maintenance and service changes during regular maintenance windows, as needed. Service changes that cannot be scheduled during regular maintenance windows will be scheduled at the Providers discretion unless otherwise noted in this Agreement. Major upgrades will be treated as projects outside the scope of a weekly maintenance window.

The Service Provider(s) agrees to publish changes that affect customers service in the ITU Maintenance Calendar located on the Alerts and Outages page. The Calendar is the official outage and maintenance schedule for the ITU.

Pricing

This section details any costs required to support this SLA. As needed, information pertaining to billing and fund transfers are included (e.g., transfer dates, organization codes, and billing exceptions).

Item Description (e.g., Hardware/Software)

Pricing

[Type Text]

[Type Cost $$]

[Type Text]

[Type Cost $$]

[Type Text]

[Type Cost $$]

Transfer Amount

Transfer From

Transfer To

Transfer By

[Type Cost $$]

[Type Org Code]

[Type Org Code]

[Type Date]

[Type Cost $$]

[Type Org Code]

[Type Org Code]

[Type Date]

Exceptions

[ List any exceptions to service costs]

Example: If the Requesting Organization terminates this agreement during the agreement period, the Organization agrees to pay all initial costs, all backup services costs, and monthly support costs for the period of service provided.

Service Review & Reporting

This agreement takes effect the date that all approval signatures are obtained. This date must be reflected on the cover page of this document. The term of this SLA is one year from its effective date.

The Service Provider(s) is responsible for facilitating regular reviews of this document. This SLA will be reviewed on an annual basis and remain valid until an associated dataset is modified or the agreement is revised or terminated. Either party may amend or terminate this agreement through written notification and pending approval of all stakeholders.

Both the Service Provider(s) and Requesting Organization(s) may amend this Agreement. The Document Owner must communicate any amendment to all affected parties in a timely manner. The Service Provider(s) agrees to revise this document as required and to obtain any necessary approvals. Amended SLAs will be held in a repository and made available to stakeholders upon request.

Data Stewardship & Security

The Administrative Data Stewardship Policy Number 1114 applies to all academic and operational departments and offices at all George Mason University locations, owned and leased and governs the data sets associated with this SLA. This policy defines Highly Sensitive Protected Data and Restricted Protected Data, as well as Public Use data. The policy also defines the Data Owner as a person authorized to manage a subset of data and responsible for ensuring that University data security policies are followed and for developing internal controls to ensure data security and privacy.

SLA Data Set Types

Select each data set type associated with this SLA:

___ Highly Sensitive Protected Data

___ Restricted Protected Data

___ Public Use Data

Name of

Data Owner

Appendix C of Policy 1114 includes authorization procedures and forms that require the user to state the business need and agree to accept the responsibility to protect the highly sensitive/restricted data. Any university employee, student or non-university individual who stores highly sensitive university data without proper permissions and protection measures is in violation of this policy and will be subject to appropriate disciplinary action, including possible dismissal and/or legal action.

Name: ______________________________________

Appendix A: Required Policies, Processes and Procedures

Policy 1114: Data Stewardship

Policy 1301: Responsible Use of Computing

DRAFT TEMPLATE

DRAFT TEMPLATE

DRAFT TEMPLATE

ITU | Service Level Agreement

10

Appendix B: IT Support Centers Urgency Table

Prioritization and Response TimesUrgency Level

Criteria

Response Time Target

Closure Time Target

1 Emergency

Major ITU services are unavailable Significant services are unavailable at multiple locations. For example:

15 minutes

4 hours

Loss of data or voice service, on entire campus, building or multiple buildings

Loss of a primary Internet link

Failure of the communications path to Banner or other critical administrative systems

Communications failures that would disrupt major events or programs at the university

Failures that disrupt GMU Police Department communications, or otherwise endanger public safety

Entire Application is inoperative A university wide application such as E-mail or Banner is unavailable.

2 High Priority

Some ITU services are unavailable There is significant impact to departmental services or functions that must be addressed quickly. Examples:

1 hour

8 hours

Communications service outage affecting multiple or high-profile customers

Discovery of a worm or compromised system that is aggressively attempting to infect other hosts

Loss of cable TV service to one or more residence hall buildings

Trouble reports, urgent requests for service, or questions from customers or outside agencies that are not considered to be emergencies, but require some type of action (either a fix or a callback) within a few hours

High Profile Customer Any personnel designated as a High Profile user is experiencing a problem.

CSIRT Computer Security Incident Response and/or virus found.

SLA Special service level agreements established with specific Mason departments such as Freedom Center and Mason Enterprise Center.

3 Standard

A Single Device is Inoperative A single workstation, printer, or peripheral device is inoperative due to hardware or operating system problems, effecting only one customer.

8 hours

16 hours

Application Software All issues with a software component for a single device, workstation, or application. For example, a local Windows password, a paper jam, adding a printer, or installing a new software package.

Accounts All requests for new LAN, calendar and generic accounts, as well as new shares or changing permissions.

Informational Request The customer has a question or needs instruction on how to use supported software.

4 Scheduled

Non-Supported Software The customer has a question or needs instruction on how to use non-supported software.

As Negotiated with Customer

As Negotiated with Customer

Installations When a customer requests installation of new software or hardware

Moves When a customer is moving, the response for the incident must be scheduled.

Projects When a customer request involves multiple actions to complete, such as re-cabling a new building, or developing a solution for a service that is not currently provided.

ITU | Service Level Agreement

12