Managed File Transfer SLAs: More Important Than Hot Pizza

Rather than dive into the Managed File Transfer (MFT) VS. Enterprise File Sync and Share (EFSS) debate, I want to talk about a critical distinguishing characteristic of any file transfersolution, be it of either strain. This characteristic is the Service Level Agreement (SLA) offered by your service vendor. But first, let’s talk about Domino’s Pizza.

 Those of us lucky enough to have lived through the eighties or nineties fondly remember Domino’s Pizza’s famous guarantee and former #1 sales message: “30 minutes or less or your pizza is free.”

 From 1979 to 1993, this simple guarantee helped build Domino’s into the world largest pizza chain, by promising customers a win-win scenario: either they got their hot, fresh pizza in 30 minutes or less, or they got it for free. Pretty enticing right?  Apparently, America thought so, because by 1993, when the guarantee was rolled back (following lawsuits over accidents caused by reckless delivery drivers), Domino’s had signed it’s 1000^th franchise, and them some. Side note: the guarantee is apparently still available in India, and I have to admit, I’m a little bit jealous.

 So why are we talking about Domino’s Pizza?

 Because that guarantee is probably the most well-known example of a Service Level Agreement, an essential part of any contract, in the world.

What is an SLA?

 The SLA is the contractual agreement between a customer and a service provider which defines the level of service, availability, and performance guaranteed to the customer.

 A typical Service Level Agreement will define the level of service expected from the service provider, the metrics used to measure service, and the penalties that are incurred when the service provider doesn’t meet the agreed upon level of service. In our Domino’s example, the metric used to measure service is time, i.e., 30 minutes. Quality is not a metric in this SLA, so if you get a crappy pizza quickly, you’re still paying (this is, in my opinion, crucial to Domino’s business model). The penalty for breaching the SLA and failing to deliver pizza in 30 minutes or less, is waiving the cost of the pizza.

An SLA is a standard part of most enterprise file transfer contracts, but just having one isn’t sufficient. Not all SLAs are made equal.  When evaluating a SLA from a potential service provider, it’s important to understand how SLAs work, and what makes a good (or bad) SLA, before you sign anything. Otherwise, you might end up waiting three hours for a crappy pizza, and nobody wants that. Let’s go over a few of the key attributes that make a good SLA.

Service Availability 

 This metric spells out the service uptime targets and outlines a credit schedule. Typically, this number should look like a series of nines—like 99.99% (i.e., the “four nines” level). At that level, you could expect just 52 minutes of downtime per year.  The credit schedule should outline what the vendor will owe you if the service they provide falls below the contractually agreed upon target. Some vendors might claim a high level of availability but don’t back that claim up with a credit schedule. If they miss their target, you have no recourse as a paying customer. That’s like getting cold, soggy pizza two hours late and paying for it anyway. To get real visibility into the service you’re paying for, you need to have an agreed-upon level of availability, along with a clear outline of what happens when the vendor fails to live up to that expectation.

Recovery Point Objective (RPO)

 The Recovery Point Objective or RPO represents the vendor’s target for retrieving your data in the event of a disaster. If a reasonable objective is 30 minutes (as in the Domino’s analogy), the vendor is setting a target of losing no more data than that stored in the 30 minutes preceding an event. For example, while it’s unlikely that a service provider would create tape backups to achieve an RPO, if that were the case, a 30-minute RPO would require tape backups every 30 minutes! Imagine leaving your pizza on the table for 5 minutes, only to have it disappear. Your vendor should guarantee your data if you’re relying on it to do business. 

Recovery Time Objective (RTO) 

 The Recovery Time Objective or RTO represents the vendor’s target time-period for returning access to your data and their service in the event of a disaster. Without an RTO, your service provider is not giving you any indication of how long the service might be down in the event of a disaster. For example, if the objective is three hours, the vendor is setting a target of no more than three hours to return access to your data via its service, following a disaster. This is effectively the equivalent of Domino’s telling you their hours, or when they’re closed for a holiday.  In 2016, when massive DDoS attacks targeted DNS provider Dyn, large portions of the internet, including consumer-grade EFSS products went down for most North Americans—for up to two hours at a time. What’s worse, back in 2013, one consumer-grade EFSS service provider was down for a 16 hour period. Who wants to wait 16 hours for their pizza?

Compliance Should be a Consideration

 While compliance hasn’t always been a top consideration in SLAs, in 2018, it should be. Under the GDPR, any liability for non-compliance ultimately comes back to the data controller, which is you, not your 3^rd-party service vendors (they’re the controller). Data controllers are not relieved of their data protection obligations if a breach occurs in a processors network. Your SLA should contain guarantees that the vendor will be compliance with the GDPR, or other regulations, like HIPAA, and that they’ll maintain an audit trail of all data processing activities so that you can ensure that compliance. There’s no good pizza analogy for this, but it’s important nonetheless.

 Service vendors may offer 100% network uptime, but it’s critically important to understand the stated application uptime. Premium cloud infrastructure environments can be up 100% of the time, but access to the hosted application is all that should matter to you. Are vendors really telling you that the application will never, ever, not even once, for a half-second, be unavailable? If it sounds too good to be true, make sure you understand the claim and have some recourse. If a service provider truly wants to be your business partner, they should be willing to share the pain in the case of an outage.

 Before signing with any vendor—Managed File Trasfer or EFFS—you should know the terms of their SLA, so that you know exactly what you’re getting. Remember to ask your vendor who’s responsible for maintaining your SLA, and what the remedies will be if they fail to live up to it. Going into an agreement without an SLA is like going in blind, or ordering a pizza, without specifying what kind, or when you want it.