Trust: The Achilles heel of SaaS

Used_car_salesman

I guarantee you that every time someone decides to use a Software as a Service (SaaS) solution for their company, there’s a specific thought that runs through their heads:

Can I trust this service with my confidential data?

This is a legitimate concern.  When you use a SaaS solution, you’re basically making your company an open book to that service.  When I took Yammer for a test drive the other day and scribbled my thoughts about it, a few people told me I was a little harsh on them.  My concerns with it were primarily around trust and how ready it is for a mid-to-large enterprise.  I love the concept, I’ve been pushing for it ever since I started using Twitter.  But, that doesn’t give companies aiming at enterprise users a free pass.  But that did get me thinking about the concept of Trust and how it relates to SaaS.

I don’t think this is a simple issue. You probably don’t care if
people outside the company see SOME data, like what type of sandwich
was served at the team lunch. Talking about what you had for lunch on
Yammer is fine. But what about HR data? Or M&A data? Certainly you
don’t want employees talking about a potential acquisition on Yammer,
because you ultimately don’t know who has access to it and there are
legal implications to people seeing it.

There’s a certain amount of trust being a well-known brand
automatically gets for you. That trust can help you get over this
"trust objection" and close the sale.
Yammer will probably not be trusted to host Cisco’s data, but I would
venture a guess that Yammer would not have a problem entrusting its
data to Cisco. It’s one of the few advantages of being big that small
startups just can’t overcome.

This also raises an interesting question: which companies have the
kind of inherent trust in their brand that they could leverage to
launch a service like Yammer and be successful with it? My short list
includes Microsoft, Salesforce.com, Cisco, Amazon, IBM, and MAYBE
Google. On the polar opposite end of the spectrum you have startups and
AOL (who has a habit of disclosing confidential customer data).

Which companies would you trust with your confidential Twitter traffic?

Share and Enjoy:
  • Print
  • Digg
  • Facebook
  • Google Bookmarks
  • HackerNews
  • Reddit
  • http://eastman1.blogspot.com DE

    Why do we trust paper mail? Someone may have read it, but they would have to break the seal on the envelope cleanly. Possible, but a high barrier to casual peaking.

    The trust issues can be solved fairly easily using simple encoding/decoding features. The issue is just lack of simplicity and client support.

    But ultimately the web is designed to spread information, not contain it. For that reason, SaaS for enterprise is a kind of anti-pattern.

  • http://guyro.typepad.com Guy Rosen

    Trust certainly is an issue, and if you cannot become part of a trusted brand, you need to ask yourself who will trust you.
    Trust is an innovation
    and I've observed that it behaves using the same adoption curve! Early adopters will very often tend to be "early trusters" (perhaps it is the tech innovations factor that allows them to risk their trust). In organizations, you'll often find the techies here.
    On the other end of the curve you will find those people who are last to entrust their data to someone else. Organizationally speaking, accountants and lawyers will most likely be around here.
    What does this mean? It means that when building and marketing your SaaS solution you need to be targeting these "early trusters", whether as your overall audience or as the entry point into the organization. This is why online bug tracking has caught on faster than online M&A workflow systems.

  • http://randykolb.com Randy

    Two thoughts on this…
    1) What makes most companies that would not trust a SaaS implementation believe they can be more secure on their own? Sure, if it’s a 100% internal solution with no external access whatsoever, they may be able to pull it off. Then again, that veneer of security may easily be shattered by an employee’s lost laptop.
    2) Certain applications will connotatively carry varying levels of implied security vulnerabilities. A product catalog doesn’t seem as large a risk as HR records (liability) nor engineering data in a PDM system (IP). Regardless of that perception you need to weigh risk tolerance for a SaaS vendor's SLA, along with their reputation—essentially, your perception that they’ll deliver on their SLA, which should include DRP, security model, SLA failure remediation, etc., as well as service availability.

  • http://www.jasonkolb.com Jason Kolb

    But are "early trusters" the ONLY trusters? From my experience working at Cisco, I can't see them EVER letting confidential data outside of the firewall.

    Apps inside the firewall are inherently more trusted, I think, because the company can easily see how the data is being used. You know that nobody's sharing the data outside the organization. A SaaS solution, on the other hand, is a black box. You really ONLY have trust to rely on.

  • http://www.kinamik.com/blog Rob

    Trust is a very interesting issue. From my point of view, besides any kind of psychological proposition for gaining a customer's (or potential customer's) trust is simply to provide hard evidence for it. Just as DE commented, you trust that your hard-copy, paper mail hasn't been opened because when you receive it you see the envelope nicely sealed. But I don't think that encoding is the answer (since the "reader" of the letter may even be an insider that knows how to decode the letter, or simply the coding key could be lost). I think that the best way to actually showing trust is providing an "electronic" envelope/seal that, if opened or tampered, can be easily seen.

    For the SaaS world this proof for trust could be easily provided by some kind of audit trails (or logs) that have a "security seal" (i.e. they must be immutable and tamper-evident).

    This way you should be able to convince even the "slow adopters" like lawyers or accountants (with maybe some help from the techies) :)