I get a never-ending stream of questions that usually amounts to something like “What control tasks do I need to do to be sure that this SaaS service we are going to use will be adequately secure?”
Unfortunately, at this point in time, SaaS providers offer relatively little support for enterprise control over anything. Assuming that the provider allows it (not all of them do), it is possible to manage the user accounts, ensuring that the right people have them, disabling them when somebody goes, and possibly controlling membership in groups or roles. If the provider offers it, and your users will put up with it, a growing number of high-end SaaS offerings allow use of strong authentication, which is increasingly important in face of the growing phishing threat. A small number of products provide some logging and records management, and in some cases, the buyer has made the choice to maintain their own backup copies of the data.
Beyond that, the whole purpose of using SaaS is to offload management onto your supplier. While I do think that we are evolving towards a model in which the enterprise provides a degree of control, and the provider does all the operations, today, we’re not really there. To a great degree, the choice to use a SaaS product is a choice to rely upon their controlling your destiny. If you do not believe that they can provide an adequate level of security, continuity, and recoverability to meet your business needs, then you shouldn’t use them.
The awkward fact in many buying situations is that no adequate determination was made up front as to a vendor’s ability to do this. What usually happens is that a decision is made, and then responsibility is dumped into someone else’s lap to ‘make it secure’. The lapholder is actually being asked to be the scapegoat. They didn’t approve of the use of the thing in the first place, they’ve got no ability to control what people are putting into it, and they’ve got neither budget nor technical mechanisms to oversee the activities, legitimate or illegitimate, taking place within their virtual presence in somebody else’s multi-tenanted service.
When the security failure does occur, or the service goes down and can’t be restored, then it is the role of the scapegoat, who recommended against the thing in the first place, to take the blame for the failure that they predicted would happen. While this may be a nice CYA mechanism for the line of business that dumped their risk into IT’s lap, it hardly seems like the basis for making an optimal economic decision as to how computing services should be delivered.
Read Complimentary Relevant Research
Cloud Computing Primer for 2017
Cloud has evolved from a disruption to an expected approach to traditional as well as next-generation IT. Our research helps IT leaders,...
View Relevant Webinars
State of Cloud Security 2017
Si affronterà la tematica di Sicurezza nel Cloud per consentire ai professionisti della sicurezza e alle loro organizzazioni di comprendere...
Category: applications cloud-computing iam it-governance risk-management security vendor-contracts
Tags: backups bcpdr cloud-computing cloud-security continuity disaster-recovery information-security malware phishing trojan-horse vendor-risk
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.