When an enterprise uses on-premises servers, they know issues they experience that prevent the servers from functioning are their problem, and they must have the resources to resolve them. This is why organizations often use redundant components, servers, or even datacenters to keep business-critical services available. Many IT professionals prefer this self-reliance; they can be confident of their continued functionality by planning and implementing their services correctly. However, an enterprise that uses cloud-based services must rely on others to keep its services running.

For IT professionals, service outages are one of the potential showstopper issues for the adoption of Microsoft 365 and other cloud-based services. If the services suffer downtime, business stops. While it might not be the IT professionals’ fault, it is their responsibility. What is worse, there is nothing they can do about it except call the provider and shout at them. Depending on the nature of the organization’s business, service downtime can result in lost productivity, lost income, and—in extreme cases—even lost lives.

To address this issue, contracts with cloud service providers typically include a service level agreement (SLA). The SLA guarantees a certain percentage of uptime for the services and specifies the consequences if that guarantee is not met. It is important to remember that an organization usually has more than one service provider that is needed to access the cloud. For example, an organization can contract with Microsoft for a certain number of Microsoft 365 subscriptions, but the reliability specified in Microsoft’s SLA means nothing if the organization’s Internet service provider (ISP) fails to provide them with access to the cloud. Therefore, an organization should have a contract with every cloud service provider they use that includes SLA terminology.

When negotiating an SLA with any cloud service provider or Internet service provider, there should be language included to address questions like the following:

• What formula is used to calculate the service levels that are actually achieved?
• Who is responsible for maintaining records of service levels?
• How and when is the subscriber provided with written reports of the service levels achieved?
• Are there exceptional circumstances specified in the SLA under which service outages are not classified as downtime?
• How much downtime is expected or allowable for the provider’s scheduled and emergency maintenance?
• What are the terms of the agreement regarding service interruptions resulting from acts of war, extreme weather, or natural disasters?
• What are the terms of the agreement regarding service interruptions caused by third-party services, such as power outages?
• What are the terms of the agreement regarding service interruptions resulting from malicious cyberattacks against the provider?
• What are the terms of the agreement regarding service interruptions resulting from malicious cyberattacks against the subscriber?
• What remedy or penalty does the provider supply when they fail to meet the agreed-upon service levels?
• What is the liability to which the provider is subject when service interruptions cause a loss of business or productivity?

These questions are designed to quantify the nature of the SLA and how it can legally affect the relationship between the provider and the subscriber. For example, a provider can guarantee a 99 percent uptime rate. However, without specific language addressing the point, there is no way to determine exactly what constitutes uptime or downtime. What if a service is only partially operational, with some tasks functional and others not? Does that constitute downtime? There is also the question of what happens when downtime in excess of the guaranteed amount does occur. Is it the responsibility of the subscriber to make a claim? If excessive downtime occurs, is the provider responsible for the subscriber’s lost business during that downtime or just for a prorated subscription fee? If issues like these are not discussed with specific language in the SLA, then they are potential arguments the provider can use to avoid supporting their uptime guarantee.

SLA Limitations

As an example of the terms that might appear in an SLA to limit the responsibility of the cloud service provider, consider the following excerpt from Microsoft’s SLA for Microsoft Entra ID (Azure Active Directory):

This SLA and any applicable Service Levels do not apply to any performance or availability issues:

Disaster, war, acts of terrorism, riots, government action, or a network or device failure external to our data centers, including at your site or between your site and our data center);

That result from the use of services, hardware, or software not provided by us, including, but not limited to, issues resulting from inadequate bandwidth or related to third-party software or services;

That results from failures in a single Microsoft Datacenter location, when your network connectivity is explicitly dependent on that location in a non-geo-resilient manner;

Caused by your use of a Service after we advised you to modify your use of the Service, if you did not modify your use as advised;

During or with respect to preview, pre-release, beta or trial versions of a Service, feature or software (as determined by us) or to purchases made using Microsoft subscription credits;

That result from your unauthorized action or lack of action when required, or from your employees, agents, contractors, or vendors, or anyone gaining access to our network by means of your passwords or equipment, or otherwise resulting from your failure to follow appropriate security practices;

That result from your failure to adhere to any required configurations, use supported platforms, follow any policies for acceptable use, or your use of the Service in a manner inconsistent with the features and functionality of the Service (for example, attempts to perform operations that are not supported) or inconsistent with our published guidance;

That result from faulty input, instructions, or arguments (for example, requests to access files that do not exist);

That result from your attempts to perform operations that exceed prescribed quotas or that resulted from our throttling of suspected abusive behavior;

Due to your use of Service features that are outside of associated Support Windows; or

For licenses reserved, but not paid for, at the time of the Incident.

These limitations are not standard for all SLAs, but they are typical.