The Decision Making Process in accepting SaaS for the Workplace
Damian Fasciani, Director of Technology at Culture Amp, a culture-first organization, shares his thoughts on how forward-thinking Technology and Security Teams at modern workplaces can observe and consult on risk levels, while giving business teams the autonomy to manage their own SaaS tools in a digital world.
SaaS (Software as a service) is a common technology that many businesses have adopted over the last ten years. Some adopted SaaS tooling early when the trend was new, others are still on their cloud journey. My first experience with the concept of SaaS offerings was back in 2007. I attempted to build out a “hosting software service” for a previous employer and while the concept at the time was new and exciting, from a liability, data and overall risk perspective there was much more to it than the technology side. Fast forward to today and nothing really has changed.
SaaS offerings today come in all shapes and sizes, searching online you will find a SaaS offering for almost anything. The concept of having to install an application on your machine is pretty niche. For businesses the idea of removing infrastructure, data centres, and IT teams that “sit in a server room” doing all the things doesn’t really need to be sold. Businesses now want to take control of the decision making process, be part of the process of what business systems are needed to amplify the workplace.
But do teams still need a Technology or Security team to help onboard the SaaS system that doesn’t need to be “installed and rolled out”?
The answer is yes, but the catch is that those Technology and Security teams need to be more business savvy and work out pretty quickly how far they need to lean in or back depending on the business need.
The fundamental question that every business should ask themselves before accepting terms and handing over money to a SaaS offering is this:
What type of data am I going to be storing in this SaaS tool, and how important is that data to my business?
The answer to that question should drive a due diligence process that businesses should be conducting prior to agreeing to take on a SaaS tool and handing your data over. The question itself may be an obvious one but I have observed many businesses, teams, and individuals skip past it and jump straight into solution mode.
As a technologist at heart, I won’t talk about technology to anyone before I understand three core things when a team thinks they need a new SaaS tool:
What is the scope of the project or the business request?
What is the current state and why do you think you need a new system to solve the problem?
What does success look like for you or your team and how will you measure that success?
There is flow on a set of questions but these are the fundamental questions and you can add the first one in relation to the data that the SaaS tool will potentially hold. Answering these questions will help a technology or security team understand the business context before assisting with the introduction of a new SaaS tool.
The due diligence process is an assessment that can be done on the security, build quality and general technology profile of a SaaS product which can help businesses make a decision if it is the right fit. This practice has become more common for larger businesses who have to comply with strict regulations around data handling. An example would be the banks, government departments, insurance companies or any type of business that takes online payments and stores credit card, PII information.
So how would a business run a due diligence process on a SaaS vendor?
A light, pragmatic process wins out because if you build something that is light, you can tailor it for future needs. Odds are if you are looking at a SaaS tool, it won’t be a once off and it will be a repetitive process. A forward thinking Technology or Security team can build out and provide a questionnaire that can be sent to Saas vendors; otherwise in this blog, I will list out some common questions that you would want a vendor to come back to you on. Over the last four to five years we have seen a percentage of SaaS vendors make their security information publicly available for consumption. This is ideal because this information can be assessed first and if you feel that there are still gaps, you can follow up on the gaps with additional questions.
Here is a common set of questions to ask a SaaS Vendor prior to committing to a contractual agreement:
Where do you host your application and where is my data stored?
Do I have a choice as to where my data is stored?
When my data is in transit and stored (at rest), is it encrypted? If so, provide the detail
Do you comply with ISO, SOC 2, GDPR or any other common frameworks, if so please list and provide evidence.
Do you make available your SOC 2 audit report findings? If so please provide the detail
How long has your business been operational?
How do you approach software development, and application security. Do you insource it or outsource this?
Who are your sub processors and what role do they play in relation to your platform
What is the process to export or extract my data out of your tool?
Do you support and integrate with SSO (Single Sign On)?
At a high level, how is your application architected specifically relating to high availability, cross regional infrastructure deployment?
Do you offer an SLA and Support service with an RTO and RPO (recovery time objective / Recovery Point Objective)?
Do you publicize an uptime and service status page so i can see the historical performance of your product?
The above questions will give you a good indication of the quality of the product you’re about to sign up for. Relating back to the fundamental question of the type of data that you would store in the system. The more critical and valuable the data is, the greater in depth you may go in running your due diligence process with that SaaS vendor. A pragmatic and re-usable approach would be to categorize the above questions into segments. This means that the less valuable the data is, you may choose to not send a vendor all the above questions. It may be just a subset. However, if you’re looking at a SaaS tool that is going to store your customer’s data then the risk appetite may not be as great so all the questions may apply.
As your SaaS footprint or your “application network” grows, then you may want to think about how you holistically monitor data, configuration, and access to those tools.
Over time as businesses have introduced multiple SaaS tools into the workplace, the nature of those tools, the data they hold, who accesses them and how they are managed all contribute to your overall “security posture”.
The status of your security posture should be driven by the risk appetite that your business has. If your risk appetite is low, then you will take risks, not conduct your due diligence and sign up to any Saas tool that has a pretty website and claims that it’s all simple to swipe a credit card and get started. If the risk appetite is high, then your approach to SaaS will be a careful, methodical approach and you will run a full check every time.
The approach to introducing SaaS tools for me falls somewhere in the middle. A lean, practice process that can scale with each and every business initiative will allow you to put the time into your research depending on the data you’re holding. Some initiatives will need an in depth review before turning on new SaaS tools, others may not. A collaborative process between Technology, Security, and the business is key.
As your SaaS footprint or your “application network” grows, then you may want to think about how you holistically monitor data, configuration, and access to those tools. This will still give your business the autonomy it wants in a digital world while also allowing Technology and Security to observe and consult on risk levels.