Sunday, November 30, 2008

The two-headed serpent of SLAs

We all know we should read EULAs (End User License Agreements) more carefully than we usually do, and we feel a little guilty every time we blindly click through one without reading it carefully.  Even with patience and tools like the EULAlyzer on our side, we don't always realize what we are getting ourselves into (or what rights we are giving up) when we break the seal, click, or do whatever signifies our acceptance of the EULA.  But we know we should worry about them, and that's a start.

twoheads

But SLAs (Service Level Agreements) are different, right?  We use SLAs to hold our vendors and service providers accountable to us, what could possibly be lurking in them to bite us?  Some things are obvious, like the phone company needs access to the premises to fix some problems- and if we don't give them access we can't hold them to their SLA.  But what if the phone company (or anyone else) needs access to an area where confidential data is stored? That could be a problem, but you have a policy for that.  Well, at least you have thought about it.  OK, you should think about it.  What about support for hardware, network systems, operating systems, and application software?  There are potential problems in the SLAs associated with these, too.  Need service on a bit of hardware?  What information is exposed when you send it out or a tech comes in?  Some network gear acting up and the vendor needs traffic captures to diagnose the problem- what will they see in that traffic?  Problems in software and the vendor requires access to the systems for troubleshooting- there's another exposure problem.  Don't want to give the vendor access or information?  Or you can't give access due to policy or compliance issues?  You may be violating your responsibility as defined in the SLA, relieving the vendor of their responsibilities you thought the SLA guaranteed.  And really, the requirements usually make sense- how good are you at diagnosing and repairing systems you can't access? 

Sounds like we need to read the fine print, identify potential problems, and come up with a plan for resolving conflicts before we get bitten by the other end of the SLA serpent.

 

Jack