FedRAMP’s Impact to Service Level Agreements

December 27, 2024

Most companies starting their FedRAMP journey have existing Service Level Agreements (SLAs), or in some cases, Service Level Objectives (SLOs) for their existing commercial cloud offering. The quality of these may range greatly from “we threw this together in response to a customer demand but have no actual ability to monitor compliance” to “our legal team and CloudOps team have defined a well thought out and measurable set of SLAs”. In this post, I will go into why and how FedRAMP will make you evaluate your existing SLAs and in many cases, give reason to update them if not already mature and measurable.

In this post, I’ll use the term SLA versus SLO to mean both. However, and SLA is backed up by some sort of compensation if the company fails to meet that metric, most often as service credits. An SLO is simply a statement that our objective is to meet this standard, but it is not backed up by any compensation. I’ve seen several companies call SLOs SLAs, and while my preference is to implement an SLA versus and SLO, each company will make their own decisions.

So, why is FedRAMP different? The first reason is that it is highly likely that a company’s FedRAMP instance is new, and not part of their standard commercial production environments. It is also unlikely that all of the tools used today to monitor uptime and performance that are already in use are FedRAMP authorized, or will be easily put into your security boundary.

The second reason is that you are selling a cloud service to the US Government, and they do things different.

Let’s start with the Federal Cloud Computing Strategy, which states that an SLA should be in place that “provides the agency with continuous awareness of the confidentiality, integrity, and availability of its information.” It goes on to discuss that the federal agencies are restricted to SLAs that meet the following criteria: “(1) the clause is required to implement a provision of law applicable to the acquisition of commercial items; or (2) the clause is generally consistent with customary commercial practice.” This does restrict the federal government from just making up ridiculous SLAs and placing them on contract. It is important to note that this guidance doesn’t limit the government to your existing SLA, only to an SLA that is consistent with commercial practice. This is where I think SLOs will hit a roadblock, since SLAs are better for the government and are customary in cloud services. I’ve seen procurements where the Request for Proposals stated the SLA that the cloud service provider was to meet. Either you agree to that SLA or you don’t bid for that work, make your choice. I’ve also seen it where they mandated monthly SLA reporting and automatic service credits. In other cases, they will just accept your standard commercial SLA. Each agency has their own way of doing business.

Just because it is in a strategy doesn’t mean that it is in practice, right? True, but it is getting more visibility and even now finding its way in Government Accounting Office (GAO) reports. In 2023, the GAO published GAO-23-105484 and called out SLAs around security metrics for four agencies. Overall, they did okay, but not perfect. However, I doubt any agency wants to be called out for not including SLAs when they could have used them. This shows that at least with these four agencies, SLAs were indeed required.

Let’s bring this back to FedRAMP. What does FedRAMP have to do with SLAs? In fact, there are several aspects of FedRAMP that either require an SLA to be stated, or if done properly, can help a company assess and improve their existing SLA.

First of all, there is the Information System Contingency Plan (ISCP). The ISCP is a mandated formatted Disaster Recovery (DR) plan. Appendix L of the ISCP, is the Business Impact Analysis (BIA), which is guided by NIST SP 800-34, (section 3.4). The BIA characterizes the components of the system based on their criticality, and prioritizes recovery. The critical items or capabilities identified in the BIA should align to your SLA. If your SLA is based on system availability, the system capabilities that “define” availability should be in your BIA. Additionally, as you develop the ISCP and its appendices, you will need to define the Maximum Tolerable Downtime, Recovery Time Objective, and Recovery Point Objective. At a minimum, these metrics should inform your discussion on your SLA and how to accurate measure compliance.

Beyond the ISCP, there are several FedRAMP controls that relate to the SLA including:

My point here is that at some point in your FedRAMP journey, you will need to look at the underlying technical architecture and the critical customer facing capabilities. At this point, it may be worth asking yourself:

1. Does our SLA adequately define what we mean by “available”?
2. Does our SLA adequately address confidentiality, integrity, and availability of the federal data that we are expected to store and process?
3. Does our disaster recovery capability provide sufficient support to meet our SLA obligations?
4. Can we adequately monitor our SLA compliance with the tools that will be available within our FedRAMP environment? If not, what’s the plan?
5. Could we report on our SLA compliance if required by contract?

It is important to think this through as a company before you go into your FedRAMP audit. Once you enter audit, your FedRAMP system will go into lock-down, and you will be severely limited in what changes you are authorized to make until you achieve your FedRAMP Authority to Operate. You do not want to be negotiating with a federal agency during this period on SLAs without a reasonable level of confidence that you can meet your future contractual obligations, or causing you to go through a partial re-audit to introduce the required technologies.

Ultimately, SLAs are a business decision, and any company can agree to an SLA knowing that they are unlikely to meet it or knowing that they can’t measure compliance. Since FedRAMP forces a company to take a new look at their architecture and capabilities, it offers a company the opportunity to really look at their existing Service Level Agreement, and to make well informed improvements to it.

Follow Optiv
LinkedIn: www.linkedin.com/company/clearshark
Facebook: www.facebook.com/optivinc
YouTube: www.youtube.com/c/OptivInc
Blog: www.optiv.com/explore-optiv-insights/blog