
A SAS 70 Type 2 audit will show a provider’s track record for data center operations, security and privacy, and asking to review such an audit is important, said Dan Druker, senior vice president of marketing and business development at Intacct. A SAS 70 audit forces a cloud apps provider to write a complete and thorough document on operational procedures.

Eran Gil, vice president of business development at Cloud Sherpas, a software developer and professional services provider specializing in Google Apps, said the more cloud apps are finding their way into the enterprise, the less important SAS 70 reports are becoming. Providers are not asked very often for SAS 70 reports, he said.

Whether you ask for a SAS 70 audit or not, it’s important to understand how the audit gets misused, Druker said. There’s no such thing as “SAS 70 Certified.” The audit doesn’t prove a provider is using the latest security and encryption. It only means they’ve thoroughly documented their policies and procedures.

The biggest question mark around cloud computing is related to security and privacy. VARs should understand if data stored in the cloud app is encrypted in the database and/or over the network, what the level of encryption is, what password controls are built in and what the privacy policies are (they should be published).

Some smaller cloud vendors don’t have robust technology infrastructures, Druker said. VARs should get information on the data center infrastructure. For instance, is it a Tier 1 data center?

A cloud app is likely to be available 24/7, but when things inevitably go wrong, are there people in place to make sure things get fixed right away? Nobody wants lengthy unplanned downtime.

The most important thing is to read the service level agreement (SLA), Druker said. The SLA outlines the expectations of uptime and response time when problems occur. It’s critical to understand what the vendor is guaranteeing.

Critical applications should have much stronger SLAs than applications that are less mission-critical, Gil said. Email going down is potentially crippling, but an add-on email app going down for a period of time may not be too troublesome.

Support functions should also be outlined, Gil said. Although the specific support functions vary by application, end-user customers are going to want to know that there will be support when they have problems.

Support functions should also be outlined, Gil said. Although the specific support functions vary by application, end-user customers are going to want to know that there will be support when they have problems.

Read the fine print, said Druker. The end-user license agreement should outline who owns the client’s data. It should explicitly say that the VAR and the VAR’s client own the data rather than the vendor. There should also be an easy way to get the data out of the system if the customer decides the application is no longer appropriate for use.

What happens if there’s an outage? Can the cloud application provider show a track record of responding to outages? This information should be available somewhere on the vendor’s website, Druker said.

If there is an outage, clients should expect to get credit, but some vendors only provide a credit if the customer notices the outage and files a complaint. Other vendors will automatically give a credit whenever there is an outage.

Different vendors have different definitions of “outage,” and that’s information that should be available to VARs and customers, Druker said. Some vendors say an outage isn’t an outage unless it’s longer than an hour, whereas others call it an outage if it’s greater than three seconds.

Most cloud vendors will have transparency websites, Druker said. The site provides information outages, performance, response times, etc. If a vendor does a good job, it should want to publish that information so customers can see it.

One key thing for the channel is how partner-centric the cloud application provider is, Gil said. The best fit is with a 70/30 or better split between partner and direct sales.