It’s hard to find a company today not using some sort of Software-as-a-Service (SaaS) application for business efficiency. Whether it’s for Marketing, Accounting, Sales or IT, all departments find value in the accessibility and ease of these solutions to streamline otherwise complex processes.
However, the ease of use SaaS applications provide the organization may overshadow some of the risks, such as downtime and security. As is the case for any third-party solution, it’s key to understand the risk profile both on your side and the provider’s end. What does daily use look like? What do you examine?
Knowing the creators and owners
Sometimes the third-party provider who is selling you the SaaS application is not the creator of the technology or platform. If this is the case, what do you know of the creator and how the technology has been created? Consider the security aspects of design and whether this technology has secured itself, by design, against common threats and ramifications.
What is the IT stance of the service provider? Unfortunately, it’s all too common for a company to become overly dependent upon a SaaS application. Then, when the application goes down on the provider’s end, the company is left helpless. Your company should have an IT resiliency plan, and the provider should also have one. It’s key to check that they do.
Knowing who has access
Consider who can share information and how it is shared. Especially if your organization is under a regulatory framework, be careful that such actions don’t risk a breach of compliance. For example, if your organization uses Google Docs or Dropbox to share and store information cross-functionally, what sort of information is shared and what could happen if that information is exposed? If there is a breach or disruption to your SaaS application, what happens to your data? Does the provider keep any of your data transferred through their technology? If so, for what reason?
There may not be any right answers here—it’s just important to know exactly what level of risk your organization is putting itself under. If you identify any unnecessary avenues for sharing information, close them off. Best to be careful, rather than risk data loss and exposure.
What contractual aspects exist around who retains what data from your organization? Can the SaaS provider limit your access to your data due to a dispute? What if they go out of business? It’s paramount to put everything in writing, even service level agreements (SLAs).
Knowing who owns what responsibilities
Make sure your IT Disaster Recovery (DR) plan delineates between you and the SaaS provider the order of operations for execution and what to do if personnel are missing. Note all responsibilities in your DR playbook and share it with the provider. The best way to understand these intricacies is to test for a disruption scenario, executing your DR plan to be sure you can actually recover in a real event. Keep your SaaS provider abreast of your testing and ask to see their testing results.
Does your SaaS provider have a DR plan? Where is your data stored, exactly? How many of your SaaS applications share a common backend datacenter (AWS Zone 1, for example)? It is important to understand the architecture, so you have a complete picture of your risk profile.
Welcome to the age of the cloud
The widespread use and accessibility of the cloud has transformed the expectations of day-to-day business. Customers demand an always-on marketplace, which means the cloud isn’t something that’s going away. Now downtime is no longer an option, as it impacts the bottom line and reputation. For this reason, it’s best to embrace the cloud, but to do so cautiously to ensure everything remains secure against any and all threats. Never make a leap to the cloud without first laying out a strategy to get there (here’s a Forbes article I wrote on this subject).
Oftentimes, organizations that own the deployment and management of their cloud prefer to do so in their own datacenters, but this could present its own set of risks. The first step to closing security gaps is understanding that using cloud—any cloud—means you are using a third-party provider in some way. For example, if you have an AWS cloud, you’re in business with Amazon.
Cloud providers usually have the resources and bandwidth to properly manage the essential maintenance aspects and testing, given how this is their core business model and, thus, perform work in the cloud all day every day.
A small-to-medium-sized business, on the other hand, may only have a limited number of IT team members and resources. And these personnel may have other, more pressing responsibilities.
For this reason, many organizations are recognizing that cloud providers are more equipped to handle security, maintenance and testing of a cloud environment, so they are offloading more responsibilities to these providers with the goal of getting out of the datacenter business altogether.
This article is published as part of the IDG Contributor Network. Want to Join?