Cyber Security and Your SaaS Ecosystem—Part 1

Cyber Security and Your SaaS Ecosystem—Part 1

How to Properly Evaluate SaaS Risk Using Your Business Context

Affordability, data accessibility, and ease of use are just a few of the reasons that 73% of organizations say nearly all their apps will be Software as a Service (SaaS) by 2020. Although SaaS is not a new concept, with some of the earliest SaaS providers such as dating back to the 1990s, the SaaS business space is broadly defined with wide variations in vendor and customer interpretations. Examples of these broad interpretations are traditional software vendors hosting their applications one customer at a time in the cloud or extending pricing models that are more like traditional license agreements than SaaS subscriptions. Though these interpretations will stabilize and standardize as the business and technology space matures, cyber security teams, third-party and enterprise risk teams, legal teams, procurement, and business teams need to work together to clearly define a shared understanding about how SaaS Application Services are vetted and qualified for use, and how risk is monitored and managed over time.

In part one of our three-part blog series on the complexity of SaaS vendor evaluation for enterprise firms, we review some of the factors that impact risk, influences organizations must consider when deciding to adopt a SaaS technology, and provide a framework for initial evaluation of SaaS vendors.  

Mind the Functionality and Risk Gap

As SaaS and cloud models have evolved, the Cloud Security Alliance has developed and maintained the Cloud Controls Matrix (CCM), which distributes responsibilities between the provider and subscriber. This framework helps cyber security professionals, auditors, and the business tie SaaS initiatives to standards, leading practices, and regulations. Using this meta-framework helps clarify the detail and provides a structure within which to consider security principles as part of evaluating the use of SaaS products. Cyber security practitioners and auditors can use this structure to educate and guide the business during the evaluation process. When used in conjunction with a firm’s risk management process the CCM is a useful tool to bridge the gap between risk and functionality.

Cloud Services Responsibility Matrix-Microsoft TechNet

Cloud Services Responsibility Matrix (source: Microsoft TechNet)

The complexity of the SaaS business model, coupled with vendors’ varying security features and business longevity, make the vendor selection process challenging. Business stakeholders often lead the charge in the vendor selection process and may be ill-suited to evaluate the risks of the technology to the business. When onboarding SaaS vendors, all too often urgency gives way to haste when it comes to fully understanding and assessing potential business and cyber risk components. Determining the trade-offs between functionality and risk remain the domain of business leaders, but they regularly do not have the advice from the specialists to weigh legal, data, and privacy protection trade-offs.

SaaS vendors, particularly newcomers to the market, are beneficiaries of this gap. To allay fears and get the sale, they highlight monolithic perspectives about the security and trustworthiness of SaaS deployments. The challenge of validating SaaS security is exacerbated by the ease of acquisition and provisioning SaaS solutions. Should their SaaS vendor fail, be acquired, or be breached, the risk to an organization is considerable. While some regulators are reinforcing limits on how much cyber security liability a responsible firm may delegate to providers, any organization planning to pass regulated or sensitive business information through SaaS applications must include cyber security requirements in their vendor evaluation process.

Navigating the Volatile SaaS Landscape

According to estimates there are over 100 SaaS firms with more than $100M in annual revenue; a level of success that takes an average of 10 years to achieve. A CrunchBase search shows almost 22,000 SaaS listings, indicating the marketplace is bloated with small and early-phase firms. Even traditional software houses like SAP AG and Oracle are battling to SaaS-ify their core cash cows in the traditional on-premise enterprise business application space. In short, this is a dynamic market place where clear winners and losers are yet to be determined.

So how does a business navigate a large and volatile SaaS marketplace where a vendor’s internal objectives, lack of resources, or transitional technology may affect its customers’ security or privacy stance? A good first step is to fully define the business situation (context) driving SaaS consideration and use it as a framework for vendor evaluation.

Conducting a SaaS Firm Context Evaluation

A context evaluation can frame the extent to which due diligence and business consideration are needed. Below is an example of a general context map using data classification and provider revenue to meter the decision process. Additional dimensions that make sense to the situation, such as growth rates, profitability, or number of customers, can be included to enhance the evaluation process. For example, perhaps an immature upstart SaaS provider has a game changing innovation that will immediately increase revenue potential, customer satisfaction, or significantly reduce cost. A large enterprise could extend its decision framework to include investment in the SaaS firm to help accelerate its maturity.


There are SaaS use cases where extended evaluation is not required. These may include point tools where there is limited exposure to the business in the event the SaaS firm goes under or experiences a security or privacy breach. This segment of SaaS providers at the low end of the security and privacy spectrum are interchangeable. These may be firms where, as part of an IT and business strategy, the SaaS product is put in place with limited or no integration, has good enough security for the use case, and requires low effort to decommission or replace.

Example: A mid-sized consulting firm planned to deploy a Professional Services Automation (PSA) platform, but had a problem managing resource schedules until the platform was selected and deployed. To solve the operational issue, the firm selected a SaaS application used by advertising and marketing firms to coordinate the schedules of staff and freelancers. The SaaS application was young and very inexpensive. The data to be included on the platform was not sensitive and care was taken to restrict personal and client information saved on the system. There was no integration to other more sensitive systems. As a result, the firm was able to implement a new scheduling system within a week and run it for nine months during the PSA selection and implementation. The firm accepted the SaaS firm’s term of use and paid on a monthly basis by credit card. This was a good example of interchangeable functionality executed with very limited risk that provided good benefits to the organization. Even if the SaaS firm failed or was breached the business impact would have been acceptable.

Some questions teams can ask to determine if a SaaS platform is interchangeable:

  • If all data is breached, do we care?
  • If the application or firm fails, what impact to cost or revenue can we expect?
  • If the application or firm fails, what will our customers, partners, or other stakeholders perceive?

At the other end of the spectrum are systems that contain data we deeply care about, that will affect cost or revenue in a manner that is material, or impact our reputation or relationship with customers, partners, or other important stakeholders significantly in the event of security, privacy, or business failure. These may be SaaS systems that process customer interactions and payments, operational systems like enterprise resource planning, or manufacturing systems. They may contain intellectual capital, research and development information, or be highly integrated with financial or other systems that contain regulated information you wish to protect.

Example: Consider the ComplyRight breach and its subsequent class action suits that claim the firm was untruthful about its data security capabilities. This SaaS system helped firms prepare tax forms and Affordable Care Act (ACA) and HIPAA paperwork. In this breach, the litigants say the firm misrepresented its encryption technologies. Let us assume if your employee or customer data was affected, it would impact at a minimum your costs and reputation. In this case, well-executed third-party risk evaluation could have identified, as Brian Krebs of “Krebs on Security” quickly did, that the firm had limited cyber security capabilities despite market claims.

In the enterprise ERP sector, there are breaches that have affected operations and customers, and research conducted by government and security firms clearly shows these systems are a target of interest by cyber attackers. As these core business applications continue to move toward cloud application services and second-tier and third-tier upstarts enter the fray, there are significant context considerations a firm should make when moving to a SaaS platform.

These examples demonstrate that a context evaluation can frame the extent to which further due diligence and business consideration are needed. Once the context of the SaaS decision had been established, it is time to evaluate the business prospects of the SaaS firm, which we will cover in part two of this series.

Revolutionary Security provides a range of advisory services that help our clients in the domains of security assessments, enterprise security testing, and strategic consulting.

Contact us today to schedule a meeting with our SaaS security specialists.

Request a Meeting


Cyber Security and Your SaaS Ecosystem—Part 2
Cyber Security and Your SaaS Ecosystem—Part 3