SLAs: What your cybersecurity vendor isn’t telling you

Service Level Agreements (SLAs) have been used in the IT world for many years as a contractual mechanism for holding service providers accountable and extracting defined payments and penalties when they mess up. Likewise, vendors have used SLAs to put their “money where their mouth is” in terms of fulfilling value promises and establishing important metrics for their customers. In reality, SLAs have not kept up with either of these purposes.

For most IT pros, once contracts are signed, the SLAs are shelved by both parties and do nothing meaningful to guide the relationship. Most enterprises are sophisticated enough to understand that any monetary compensation for a vendor’s failure to perform is likely to be so insignificant as not to warrant the effort. Similarly, SMBs may lack the technical resources or manpower to properly document vendor failures, and pursuing remedies from vendors is likely #599 on the top-600 list of priorities.

SLAs from security software and services companies tend to be even more meaningless than those from IT. The reason is anchored in the universal truth that no security offering can guarantee 100 percent effectiveness. Also, a service outage from a threat scanning company, for example, might allow a catastrophic incident to occur or it might not.

If nothing happens, the likelihood of a pursuit for damages by the customer are slight. If a breach does occur, there are bigger issues at stake and most likely will turn on legal issues beyond the SLA in the contract.

So, if SLAs are virtually worthless in practice, why do we still use them?

The reality is that they can be useful if we evolve the purpose. While SLAs may have previously served as a “stick” intended to punish a vendor, we should now think of them as engagement scripts and scorecards. SLAs do serve a purpose. Here they are:

Defining the relationship

SLAs today are focused almost entirely on a vendor’s obligations and penalties – boilerplate language that is applied to every contract. Although some SLAs do include customer obligations, they tend to be vague. The reality is that SLAs should be the agreement that capture both party’s obligations, but more importantly lays out the pathway for resolution of any potential issues. In coordinating metrics, it’s imperative that vendors not be penalized for errors or mistakes that occur on the customer’s end.

Likewise, vendors need to understand their customers’ infrastructure realities and how any proprietary systems might impact their ability to provide their service. Vendors also need to understand how issues are handled and escalated through the customer’s organization.

SLAs are an excellent tool for forcing customers and vendors to work out any differences before engagements begin. Also, SLAs should live separate from contracts insomuch as they might evolve mid-engagement if needed. For example, there could be a case for adding or removing metrics months or years into an engagement.

Resolution pathway

The focus of SLAs is all too often on service level breaches and defining penalties, when those should be actions of last resort. SLAs should clearly define the dispute resolution process and encourage a cooperative effort between IT professionals – before the lawyers get involved. SLAs should capture the mutual motivation that both parties have in settling disagreements.

While the power should rest with the customer, useful SLAs have provisions that allow vendors appropriate timeframes and methods for presenting disputed data points, along with specific plans for resolving disputes.

Teeth

Although SLAs can be useful in connecting customer and vendor across a variety of potential issues, to be truly useful they must have provisions that ensure customers receive the contracted value. If enough service level breaches occur – or if they are severe enough – customers should be entitled to restitution at the expense of the vendor.

In addition to monetary guarantees for clear violations, customers should have whatever reporting or technical support time is necessary to correct issues. In cases of security incidents, quick response by triage experts should be highly valued. As far as refunds go, it is worth mentioning that the current trend of “service credits” that must be claimed like rebates or other similarly silly SLA remedies (during a specified timeframe) end up being more trouble than they are worth.

Bottom line, SLAs in cybersecurity are useful. More effort needs to be made to evolve these agreements away from being based solely on uptime or availability, and instead reflect our new paradigm of limitless complexity, layered systems, and continuous development realities to meet ever-increasing security threats. It’s time SLAs become practical agreements between technologists.