CHAPTER 2: SERVICE LEVEL AGREEMENTS (SLA)

Desired Learning Outcomes:

(1) Understand SLA and its contents.
(2) Discuss Application and System Log and Exception Report.
(3) Understand Incident and Problem Management.
(4) Create Tickets and analyze reports on Service Requests, Incident, and Problem
Tickets in Jira Service Management.

What are Service Level Agreements (SLAs) and Operational Level

Agreements (OLAs)?

Service Level Agreement and Operational Level Agreement

Service Level Agreement

• The Service Level agreement is a contract between service provider and
customer
• SLAs can also be supported by operational level agreements (OLAs)
Operational Level Agreement
• OLA is an agreement between the internal support groups of an institution
that supports SLA
• The OLA clearly depicts the performance and relationship of the internal
service groups.
• The main objective of OLA is to ensure that all the support groups provide
the intended Service Level Agreement

Tools to monitor efficiency and effectiveness of services provided:

Exception reports
These automated reports identify all applications that did not successfully
complete or otherwise malfunctioned.
An excessive number of exceptions may indicate:
• Poor understanding of business requirements
• Poor application design, development or testing
• Inadequate operation instructions
• Inadequate operations support
• Inadequate operator training or performance monitoring
• Inadequate sequencing of tasks

Information Systems Operations and Maintenance (AIS 5)

 • Inadequate system configuration
• Inadequate capacity management

System and application logs

Refers to logs generated from various systems and applications
Using this software, the auditor can carry out tests to ensure that:
• Only approved programs access sensitive data
• Only authorized IT personnel access sensitive data
• Software utilities that can alter data files and program libraries are used only
for authorized purposes
• Approved programs are run only when scheduled and, conversely, that
unauthorized runs do not take place
• The correct data file generation is accessed for production purposes
• Data files are adequately protected

Operator problem reports – Manual report used by helpdesk to log computer

operations problems & resolutions

Operator work schedules – Report maintained manually by IS management to

assist in human resource planning to ensure proper staffing of operation support

Incident Management and Problem Management

Incident management
• An Incident is an event that could lead to loss of, or disruption to, an
organization’s operations, services or functions.
• Incident management is a term describing the activities of an organization
to identify, analyze, and correct hazards to prevent a future re-occurrence.
• These incidents within a structured organization are normally dealt with by
either an (IRT) or an incident management team (IMT)
• Incident management is reactive and its objective is to respond to and
resolve issues restoring normal service (as defined by the SLA) as quickly as
possible.

Problem management
• Problem management is the process responsible for managing the lifecycle
of all problems that happen or could happen in an IT service.

Information Systems Operations and Maintenance (AIS 5)

 • The primary objectives of problem management are to prevent problems
and resulting incidents from happening, to eliminate recurring incidents,
and to minimize the impact of incidents that cannot be prevented.

Service-level agreement (SLA)

A service-level agreement (SLA) is a contract between a service provider and its

customers that documents what services the provider will furnish and defines the
service standards the provider is obligated to meet.

A service-level commitment (SLC) is a broader and more generalized form of an

SLA. The two differ because an SLA is bidirectional and involves two teams. In
contrast, an SLC is a single-directional obligation that establishes what a team can
guarantee its customers at any given time.

Why are SLAs important?

Service providers need SLAs to help them manage customer expectations and
define the severity levels and circumstances under which they are not liable for
outages or performance issues. Customers can also benefit from SLAs because the
contract describes the performance characteristics of the service -- which can be
compared with other vendors' SLAs -- and sets forth the means for redressing
service issues.

The SLA is typically one of two foundational agreements that service providers have
with their customers. Many service providers establish a master service agreement
to establish the general terms and conditions in which they will work with
customers.

The SLA is often incorporated by reference in the service provider's master service
agreement. Between the two service contracts, the SLA adds greater specificity
regarding the services provided and the metrics that will be used to measure their
performance. Service commitments define the services that are included with the
service offering.

When IT outsourcing emerged in the late 1980s, SLAs evolved as a mechanism to

govern such relationships. Service-level agreements set the expectations for a
service provider's performance and established penalties for missing the targets
and, in some cases, bonuses for exceeding them. Because outsourcing projects
were frequently customized for a particular customer, outsourcing SLAs were often
drafted to govern a specific project.

Information Systems Operations and Maintenance (AIS 5)

As managed services and cloud computing; services become more prevalent, SLAs
evolve to address the new approaches. Shared services, rather than customized
resources, characterize the newer contracting methods, so service-level
commitments are frequently used to produce broad agreements that are intended
to cover all of a service provider's customers.

Who needs a service-level agreement?

SLAs are thought to have originated with network service providers but are now
widely used in a range of IT-related fields. Some examples of industries that
establish SLAs include IT service providers and managed service providers, as well
as cloud computing and internet service providers.

Information Systems Operations and Maintenance (AIS 5)

Corporate IT organizations, particularly those who have embraced IT service
management, enter SLAs with their in-house customers -- users in other
departments within the enterprise. An IT department creates an SLA so that its
services can be measured, justified and perhaps compared with those of
outsourcing vendors.

Key components of an SLA

Key components of a service-level agreement include:

Agreement overview. This first section sets forth the basics of the agreement,
including the parties involved, the start date and a general introduction of the
services provided.

Description of services. The SLA needs detailed descriptions of every service

offered, under all possible circumstances, with the turnaround times included.
Service definitions should include how the services are delivered, whether
maintenance service is offered, what the hours of operation are, where
dependencies exist, an outline of the processes and a list of all technology and
applications used.

Exclusions. Specific services that are not offered should also be clearly defined to
avoid confusion and eliminate room for assumptions from other parties.

Service performance. Performance measurement metrics and performance levels

are defined. The client and service provider should agree on a list of all the metrics
they will use to measure the service levels of the provider.

Redressing. Compensation or payment should be defined if a provider cannot

properly fulfill their SLA.

Stakeholders. Clearly defines the parties involved in the agreement and

establishes their responsibilities.

Security. All security measures that will be taken by the service provider are
defined. Typically, this includes the drafting and consensus on antipoaching, IT
security and nondisclosure agreements.

Risk management and disaster recovery. Risk management processes and a

disaster recovery plan are established and clearly communicated.

Information Systems Operations and Maintenance (AIS 5)

Service tracking and reporting. This section defines the reporting structure,
tracking intervals and stakeholders involved in the agreement.

Periodic review and change processes. The SLA and all established key
performance indicators (KPIs) should be regularly reviewed. This process is defined
as well as the appropriate process for making changes.

Termination process. The SLA should define the circumstances under which the
agreement can be terminated or will expire. The notice period from either side
should also be established.

Signatures. Finally, all stakeholders and authorized participants from both parties
must sign the document to show their approval of every detail and process.

What are the three types of SLAs?

There are three basic types of SLAs: customer, internal and multilevel service-level
agreements.

Information Systems Operations and Maintenance (AIS 5)

A customer service-level agreement is between a service provider and its external
customers. It is sometimes called an external service agreement.

In a customer-based SLA, the customer and service provider come to a negotiated

agreement on the services that will be provided. For example, a company may
negotiate with the IT service provider that manages its accounts payable system to
define their specific relationship and expectations in detail.

A customer service-level agreement includes:

• exact details of the service expected by the customer;
• provisions of the service availability;
• standards for each level of service;
• each party's responsibilities;
• escalation procedures; and
• terms for cancellation.

An internal SLA is between an organization and its internal customer -- this could
be another organization, department or site.

That means that although a company could have an SLA open with each of its
customers, it might also have a separate SLA between its marketing and sales
departments.

For instance, a company's sales department has nearly $10,000 worth of sales every
month, with each sale worth $500. If the sales team's average closing rate is 20%,
then sales knows that marketing must deliver at least 100 qualified leads every
month.

So, the head of the organization's marketing department can work with the head
of the sales department on an SLA that stipulates that the marketing department
will deliver 100 qualified leads to the sales director by a specific date every month.

This service-level agreement could stipulate that it will include four weekly status
reports every month sent from marketing to sales to ensure the leads the sales
team is getting are enabling them to hit their monthly sales goal.

A multilevel SLA will divide the agreement into various levels that are specific to a
series of customers using the service. For example, a software as a service (SaaS)
provider might offer basic services and support to all customers using a product,

Information Systems Operations and Maintenance (AIS 5)

but they could also offer different price ranges when buying the product that
dictates different service levels. These different levels of service will be layered into
the multilevel SLA.

SLA examples
One specific example of an SLA is a data center service-level agreement. This SLA
will include:
• An uptime guarantee that indicates the percentage of time the system
is available. Nothing less than a 99.99% uptime should be considered
acceptable for modern, enterprise-level data centers.
• A definition of proper environmental conditions. This should include
oversight and maintenance practices as well as heating and cooling
standards.
• The promise of technical support. Customers must be confident that data
center staff will respond quickly and effectively to any problem, and they
will be available at any time to address it.
• Detailed security precautions that will keep the customer's assets
secure. This could include cybersecurity measures that protect against
cyberattacks, as well as physical security measures that restrict data center
access to authorized personnel. Physical security features could include two-
factor authentication, gated entries, cameras and biometric authentication.

Another specific example of an SLA is an internet service provider service-level

agreement. This SLA will include an uptime guarantee, but it will also define packet
delivery expectations and latency. Packet delivery refers to the percentage of data
packets that are received compared to the total number of data packets sent.
Latency is the amount of time it takes a packet to travel between clients and
servers.

How to validate SLA levels

Verifying the provider's service delivery levels is necessary to the enforcement of a
service-level agreement. If the SLA is not being properly fulfilled, then the client
may be able to claim the compensation agreed upon in the contract.

Most service providers make their service-level statistics available through an

online portal. This allows customers to track whether the proper service level is
being maintained. If they find it is not, the portal also allows clients to see if they're
eligible for compensation.

Information Systems Operations and Maintenance (AIS 5)

These systems and processes are frequently controlled by specialized third-party
companies. If this is the case, then it is necessary for the third party also to be
included in the SLA negotiations. This will provide them with clarity about the
service levels that should be tracked and explanations of how to track them.

Tools that automate the capturing and displaying of service-level performance

data are also available.

SLAs and indemnification clauses

An indemnification is a contractual obligation made by one party -- the indemnitor
-- to redress the damages, losses and liabilities experienced by another party -- the
indemnitee -- or by a third party. Within an SLA, an indemnification clause will
require the service provider to acknowledge that the customer is not responsible
for any costs incurred through violations of contract warranties. The
indemnification clause will also require the service provider to pay the customer
for any litigation costs from third parties that resulted from the contract breach.

To limit the scope of indemnifications, a service provider can:

• consultant an attorney;
• limit the number of indemnitees;
• establish monetary caps for the clause;
• create time limits; and
• define the point at which the responsibility of indemnification starts.

SLA performance metrics

SLAs include metrics to measure the service provider's performance. Because it can
be challenging to select metrics that are fair to the customer and the service
provider, it's important that the metrics are within the control of the service
provider. If the service provider is unable to control whether a metric performs as
specified, it's not fair to hold the vendor accountable for that metric.

And it should be easy to accurately collect the data for the metrics -- capturing the
data automatically would be best. In addition, the SLA should specify a reasonable
baseline for the metrics, which can be refined when more data is available on each
metric.

SLAs establish customer expectations regarding the service provider's performance

and quality in several ways. Some metrics that SLAs may specify include:

Information Systems Operations and Maintenance (AIS 5)

 • Availability and uptime percentage. The amount of time services are
running and accessible to the customer. Uptime is generally tracked and
reported per calendar month or billing cycle.
• Specific performance benchmarks. Actual performance will be
periodically compared to these benchmarks.
• Service provider response time. The time it takes the service provider to
respond to a customer's issue or request. A larger service provider may
operate a service desk to respond to customer inquiries.
• Resolution time. The time it takes for an issue to be resolved once logged
by the service provider.
• Abandonment rate. The percentage of queued calls customers abandon
while waiting for answers.
• Business results. Using KPIs to determine how service providers'
contributions affect the performance of the business.
• Error rate. The percentage of errors in a service, such as coding errors and
missed deadlines.
• First-call resolution. The percentage of incoming customer calls that are
resolved without the need for a callback from the help desk.
• Mean time to recovery. The time it takes to recover after a service outage.
• Security. The number of undisclosed vulnerabilities, for example. If an
incident occurs, service providers should demonstrate that they've taken
preventive measures.
• Time service factor. The percentage of queued calls customer service
representatives answer within a given time frame.
• Turnaround time. The time it takes for a service provider to resolve a
specific issue once it has been received.

Other metrics include the schedule for notification in advance of network changes
that may affect users and general service usage statistics.

An SLA may specify availability, performance and other parameters for different
types of customer infrastructure, including internal networks, servers and
infrastructure components, such as uninterruptable power supplies.

What happens if agreed-upon service levels aren't met?

Service-level agreements include agreed-upon penalties in the event a service
provider doesn't meet the agreed-upon service levels. These remedies could be
fee reductions or service credits against the fees incurred by the customer, as well
as termination of the contract for repeated failures.

Information Systems Operations and Maintenance (AIS 5)

Customers can enforce these service credits when service providers miss agreed-
upon performance standards. Typically, the customer and the service provider
agree to put a certain percentage of the monthly fees at risk. The service credits
are taken from those at-risk fees when the vendor misses the SLAs.

The SLA should detail how the service credits will be calculated. For example, the
customer and the vendor could develop a formula that provides service credits
based on the amount of downtime that exceeds the terms of the SLA. A service
provider may cap performance penalties at a maximum dollar amount to limit
exposure.

The SLA will also include a section detailing exclusions, that is, situations in which
an SLA's guarantees -- and penalties for failing to meet them -- don't apply. The
list might include events such as natural disasters or terrorist acts. This section is
sometimes referred to as a force majeure clause, which aims to excuse the service
provider from events beyond its reasonable control.

Penalties
The SLA penalties are disciplinary measures that exist to ensure the terms of the
contract are maintained. These penalties differ from contract to contract. They are
as follows:
• Service availability. Includes factors such as network uptime, data center
resources and database availability. Penalties should be added as deterrents
against service downtime, which could negatively affect the business.
• Service quality. Involves performance guarantee, the number of errors
allowed in a product or service, process gaps and other issues that pertain
to quality.

In addition to service credits, there could be:

• Financial penalties. Requiring the vendor to reimburse the customer the

amount of damages agreed upon in the contract.
• License extension or support. Requires the vendor to extend the term of
the license or offer the customer additional support without charge. This
could include development and maintenance.

These penalties must be specified in the language of the SLA or they won't be
enforceable. In addition, some customers may not think the service credit or license
extension penalties are adequate compensation as they may question the value of

Information Systems Operations and Maintenance (AIS 5)

continuing to receive the services of a vendor that is unable to meet its quality
levels.

Consequently, it may be worthwhile to consider a combination of penalties, as well

as include an incentive, such as a monetary bonus, for work that is more than
satisfactory.

Considerations for SLA metrics

When choosing which performance metrics to include in the SLA, a company
should consider the following factors.

The measurements should motivate the right behavior. When defining the metrics,
both parties should remember that the metrics' goal is to motivate the appropriate
behavior on behalf of the service provider and the customer.

The metrics should only reflect factors that are within the service provider's
reasonable control. The measurements should also be easy to collect. Furthermore,
both parties should resist choosing excessive amounts of metrics or measurements
that produce large amounts of data. However, including too few metrics can also
be a problem, as missing one could make it look like the contract has been
breached.

For the established metrics to be useful, a proper baseline must be established with
the measurements set to reasonable and attainable performance levels. This
baseline will likely be redefined throughout the parties' involvement in the
agreement, using the processes specified in the periodic review and change section
of the SLA.

Earn backs
An earn back is a provision that may be included in the SLA that allows providers
to regain service-level credits if they perform at or above the standard service level
for a certain amount of time. Earn backs are a response to the standardization and
popularity of service-level credits.

Service-level credits, or, simply, service credits, should be the sole and exclusive
remedy available to customers to compensate for service-level failures. A service
credit deducts an amount of money from the total amount to be paid under the
contract if the service provider fails to meet service delivery and performance
standards.

Information Systems Operations and Maintenance (AIS 5)

If both parties agree to include earn backs in the SLA, then the process should be
defined carefully at the beginning of the negotiation and integrated into the
service-level methodology.

When to revise an SLA

A service-level agreement isn't a static document. Rather, an SLA should be
updated and reviewed regularly with new information. Most companies revise their
SLAs either annually or bi-annually. However, the faster an organization grows, the
more often it should review and revise its SLAs.

Knowing when and when not to make changes in an SLA is a key part of managing
the client/service provider relationship. The two parties should meet on a set
schedule to revisit their SLA and ensure it's still meeting the requirements of both
parties.

An SLA should be revised:

• when the customer's business requirements have changed, e.g., its
availability requirements increase because it has established an e-commerce
website;
• if there's a change in workloads;
• if measurement tools, processes and metrics have improved;
• when the service provider stops offering an existing service or adds a new
service; and
• when the service provider's technical capabilities change, e.g., new
technology or more reliable equipment enables the vendor to provide faster
response times; however, the service provider should review its SLA every
18 to 24 months even if its capabilities or services haven't changed all that
much to reduce inaccurate or out-of-date content.

Service Level Agreement (SLA) Examples and Templates

Most service providers understand the need for service level agreements with their
partners and customers. But creating one might feel daunting, like you don’t know
where to start or what to include. In this article, we’re sharing some examples and
templates to help you create SLAs.

Information Systems Operations and Maintenance (AIS 5)

What is an SLA?
A service level agreement (SLA) is a documented agreement between a service
provider and a customer that identifies both the services required and the expected
level of service. The agreement varies between vendors, services, and industries.

Before subscribing for an IT service, the SLA should be carefully evaluated and
designed to realize maximum service value from an end-user and business
perspective. Service providers should pay attention to the differences between
internal outputs and customer-facing outcomes, as these can help define the
service expectations.

Writing SLAs: an SLA template

The SLA is a documented agreement. Let’s look at a sample SLA that you can use
as a template for creating your own SLAs. Remember that these documents are
flexible and unique. Make changes as necessary, as long as you include the
relevant parties—particularly the Customer. And consider additional topics you
may want to add agreements on, such as:
• Review or monitoring. How often the Service Provider and Customer may
review the SLA, perhaps annually.
• Service credits. Something the Service Provider may offer in case your
SLA is not achieved.
• Rider. Used when amendments occur.
• End-of-contract or liquidation terms. Defining how and when Customer
or Service Provider can opt out of the SLA.

There are several ways to write an SLA. Below is a mock table of contents (TOC),
which you can use as a starting template for writing your own service level
agreements.

Information Systems Operations and Maintenance (AIS 5)

Now, we’ll break down each section with a few details and examples.

1.0 Service Level Agreement

The first page of your document is simple yet important. It should include:

• Version details
• Document change history, including last reviewed date and next
scheduled review
• Document approvals

Document details & change history

Version Date Description Authorization

… … … …

Information Systems Operations and Maintenance (AIS 5)

 Document approvals

Name Role Signature Date

… … … …

Last Review: MM/DD/YYYY

Next Scheduled Review: MM/DD/YYYY

2.0. Agreement Overview

The next section, the agreement overview should include four components:
1. SLA introduction
2. Definitions, convention, acronyms, and abbreviations (A glossary)
3. Purpose
4. Contractual parameters

2.1. SLA Introduction

Include a brief introduction of the agreement, concerning parties, service scope
and contract duration. For instance:

This is a Service Level Agreement (SLA) between [Customer] and [Service Provider].
This document identifies the services required and the expected level of services
between MM/DD/YYYY to MM/DD/YYYY.

Subject to review and renewal scheduled by MM/DD/YYYY.

Signatories:

2.2. Definitions, Conventions, Acronyms, and Abbreviations

Include a definition and brief description terms used to represent services, roles,
metrics, scope, parameters, and other contractual details that may be interpreted
subjectively in different contexts. This information may also be distributed across
appropriate sections of this document instead of collated into a single section.

Information Systems Operations and Maintenance (AIS 5)

 Term Description

SLA Service Level Agreement

Degree of conformance between a result

Accuracy specification and standard value.

The characteristic representing performance of

action that leaves sufficient time remaining so
Timeliness as to maintain SLA service expectation.

IT Operations A unit of [Customer] responsible for internal IT

Department Operations.

… …

2.3. Purpose
This section defines the goals of this agreement, such as:

The purpose of this SLA is to specify the requirements of the SaaS service as defined
herein with regards to:
• Requirements for SaaS service that will be provisioned to [Customer]
• Agreed service targets
• Criteria for target fulfilment evaluation
• Roles and responsibilities of [Service Provider]
• Duration, Scope and Renewal of this SLA contract
• Supporting processes, limitations, exclusions and deviations.

2.4. Contractual Parameters

In this section, you’ll want to define the policies and scope of this contract related
to application, renewal, modification, exclusion, limitations and termination of the
agreement.

This section specifies the contractual parameters of this agreement:

Information Systems Operations and Maintenance (AIS 5)

 1. Contract renewal must be requested by [Customer] at least 30 days prior to
expiration date of this agreement.
2. Modifications, amendments, extension and early termination of this SLA must
be agreed by both signatory parties.
3. [Customer] requires a minimum of 60 days’ notice for early termination of
this SLA.
4. …

3.0. Service Agreement

This section can include a variety of components and subsections. into the
following components:
1. KPIs and metrics
2. Service levels, rankings, and priority
3. Service response
4. Exceptions and limitations
5. Responses and responsibilities
6. Service Management

3.1. KPIs and Metrics

Key performance indicators (KPIs) and other related metrics can and should
support your SLA, but the achievement of these alone does not necessarily result
in the desired outcome for the customer.

Metric Commitment Measurement

Availability MTTR

Reliability MTTF

Issue Recurrence

… … …

Information Systems Operations and Maintenance (AIS 5)

3.2. Service Levels, Rankings, and Priority

Severity Target
Level Description Response

1. Outage SaaS server down Immediate

Within 10
2. Critical High risk of server downtime minutes

Within 20
3. Urgent End-user impact initiated minutes

Potential for performance Within 30

4. Important impact if not addressed minutes

Issue addressed but

potentially impactful in the Within one
5. Monitor future business day

6.
Informational Inquiry for information Within 48 hours

… … …

Information Systems Operations and Maintenance (AIS 5)

3.3. Service Response

3.4. Exceptions and Limitations

Include any exceptions to the SLA conditions, scope, and application, such as:

This SLA is subject to the following exceptions and special conditions:

• [Service Provider] must ensure Cloud Service A availability of 99.9999%
during holiday season dated MM/DD/YYYY to MM/DD/YYYY.
• [Service Provider] may not be liable to credit reimbursement for service
impact to data centers in Region A and Region B due to natural disasters.
• Response to requests of Severity Level 6 or below by [Customer] can be
delayed up to 24 hours during the aforementioned holiday season.
• Requests for special arrangements by [Customer] may be expedited as per
pricing structure specified in Appendix A.1.

3.5. Responses and Responsibilities

Here, you’ll define the responsibilities of both the service provider and the
customer.

[Customer] responsibilities:

Information Systems Operations and Maintenance (AIS 5)

 • [Customer] should provide all necessary information and assistance related
to service performance that allows the [Service Provider] to meet the
performance standards as outlined in this document.
• [Customer] shall inform [Service Provider] regarding changing business
requirements that may necessitate a review, modification, or amendment of
the SLA.
• …

[Service Provider] responsibilities

• [Service Provider] will act as primary support provider of the services herein
identified except when third-party vendors are employed who shall assume
appropriate service support responsibilities accordingly.
• [Service Provider] will inform [Customer] regarding scheduled and
unscheduled service outages due to maintenance, troubleshooting,
disruptions or as otherwise necessary.
• …

3.6. Service Management

Include service management and support details applicable to the service
provider in this section

3.6.1. Service Availability

Service coverage by the [Service Provider] as outlined in this agreement follows the
schedule specified below:
• On-site support: 9:00 A.M. to 6:00 P.M, Monday to Friday between January 5,
2020 to December 20, 2020.
• Phone Support: 24-Hours as per Section 3.2. of this agreement.
• Email Support: 24-Hours as per Section 3.2. of this agreement.
• …

References and Glossary

Include reference agreements, policy documents, glossary and relevant details in
this section. This might include terms and conditions for both the service provider
and the customer, and any additional reference material, like third-party vendor
contracts.

Information Systems Operations and Maintenance (AIS 5)

Appendix
The appendix is a good place to store relevant information that doesn’t fit
elsewhere, such as pricing models and charges. The following section is an example
of information you may want to append to your SLA.

A.1. Pricing models and charges

Include the pricing models for each service type with detailed specifications.

Type –
Service Capacity Throughput Price

Cloud Storage A

Option

A 500GB HDD – 250 MB/s $5.00/Mo

B 10TB SSD – 500 MB/s $10.00/Mo

C 50TB SSD – 1000 MB/s $15.00/Mo

Additional
Storage

A.1 100GB HDD – 250 MB/s $1.00/Mo

B.1 2TB SSD – 500 MB/s $2.00/Mo

C.1 10TB SSD – 1000 MB/s $4.00/Mo

… … … …

SLA best practices

Though your SLA is a documented agreement, it doesn’t need to be lengthy or
overly complicated. It is a flexible, living document. My word of advice? Build one

Information Systems Operations and Maintenance (AIS 5)

using this template and examples and consult with your customers for any
perceived gaps. As unforeseen instances are inevitable, you can revisit and tweak
the SLA as needed.

Reference:
InfosecTrain. (2020). CISA Domain 4 – Information Systems Operations,
Maintenance And Service Management. Retrieved from:
https://www.infosectrain.com/blog/cisa-domain-4-information-systems-
operations-maintenance-and-service-management/#part2

Raza, M. (2019). Service Level Agreement (SLA) Examples and Template. Retrieved
from:
https://www.bmc.com/blogs/sla-template-examples/

Rosencrance, L., Louissaint, S. & Brush, K. (2021). Service-level agreement (SLA).

Retrieved from:
https://www.techtarget.com/searchitchannel/definition/service-level-
agreement#:~:text=A%20service%2Dlevel%20agreement%20(SLA)%20is%20a%2
0contract%20between,generalized%20form%20of%20an%20SLA.

Information Systems Operations and Maintenance (AIS 5)