SaaS and Compliance 

If your business is subject to compliance, whether it’s based on the law or industry rules, your Software-as-a-Service (SaaS) applications will be part of the picture. Like any other area of the IT estate, your SaaS apps must enable compliance. This article explores the issue and offers some recommendations for how to keep your SaaS apps in compliance with relevant regulations and standards.

Image Credits: Suridata

What is SaaS compliance?

To understand what SaaS compliance is, it’s worth stepping back and considering the relationship between technology and compliance in general. While certain kinds of compliance are not specifically about technology at all, such as financial controls in Sarbanes-Oxley, in reality nearly every aspect of compliance connects to some type of information technology. Given that businesses use computers for virtually all operational and financial processes, whatever software, infrastructure, and data that affects those processes is subject to compliance. 

SaaS is no exception. Just as consumers’ personal identifiable information (PII) is regulated by privacy laws when it’s stored in on-premises data systems, it is also subject to those laws when it is stored on a SaaS application. It does not matter that the SaaS app runs on the SaaS vendor’s infrastructure. You are still responsible for ensuring compliance. The difference with SaaS is that some of the compliance is your job, while other things, like security of infrastructure, is the duty of the SaaS vendor. 

In practice, this means ensuring that your business meets the criteria set by a compliance certifying organization. For example, with Payment Card Industry Data Security Standard (PCI DSS), your SaaS vendor will have to pass a PCI DSS certification audit. And, whatever systems you have that integrate with that SaaS app will need to possess controls that can pass a PCI DSS certification audit.

Examples of SaaS compliance

Here are some of the more common areas of compliance that bear on SaaS applications:

The General Data Protection Regulation (GDPR) — This European Union (EU) law is intended to protect individuals’ privacy. It ensures data rights for EU residents, which translates into compliance obligations on the part of businesses. Violating GDPR can result in serious fines. The law gives EU residents a great deal of control over their personal data. For example, they can access their data, erase it, or correct errors in it. SaaS comes into play if a business is storing EU residents’ private data on the SaaS app, e.g.,through a customer relationship management (CRM) system. To be SaaS compliant, the SaaS vendor has to provide the kind of data access and reporting that the law requires. On a related front, some European laws require “data sovereignty,” which calls for storing a Citizens’ data in their country of residence e.g., German citizens’ data must be stored in Germany, and so forth. In this case, a SaaS vendor must be able to store data in the right country—and be able to demonstrate to auditors that it has done so. 

Service Organization Control 2 (SOC2) — SOC2 is an audit process based on the American Institute of Certified Public Accountants (AICPA) Auditing Standards Board’s Trust Services Criteria (TSC). SOC2 verifies if a company’s IT systems follow TSC principles, which mostly have to do with secure management of customer data. Becoming SOC2 certified means developing and enforcing stricture data security policies. Many popular SaaS applications, particularly those that deal with business transactions, have passed a SOC2 audit. 

The International Organization for Standardization (ISO) ISO/IEC 27001 — This is nota regulation or industry-specific set of rules. Rather, ISO/IEC 27001 is a standard, a collection of guidelines for information security. In terms of SaaS, ISO/IEC 27001 recommends policies for entrusting data to a third party, such as a SaaS vendor. 

Health Insurance Portability and Accountability Act (HIPAA) — This 1996 US law requires certain kinds of healthcare data, such as patient medical records, to be stored on infrastructure owned by the healthcare provider. The provider must pass aHIPAA audit, which may involve demonstrating that the provider is not storing patient data in a SaaS system. 

PCIDSS — this multi faceted security standard was developed by The PCI Security Standards Council, which represents the payment card industry. It is not a law like GDPR, but it is required for businesses that process payment card transactions.Any SaaS vendor that wants to handle payment cards must pass a PCI DSS certification. For SaaS customers, the PCI DSS audit process may examine how a SaaS provider handles customer card information. It looks at security management, software design, policies, and procedures. 

Other regulatory schemes that can affect how SaaS vendors operate, as well as how their customers interact with SaaS, include the New York Cybersecurity Regulations, which deal with financial services firms’ cybersecurity, and rules from the Federal Financial Institutions Examination Council (FFIEC).

Getting SaaS compliant

Making sure your company’s SaaS is compliant need not be a major undertaking. In some cases, it will merely involve checking that your SaaS vendors are compliant with relevant compliance requirements. On your end, you have to understand where SaaS apps handle data that’s applicable to compliance. For example, if you have a SaaS-based enterprise resource planning (ERP) system, you need to know what financial and customer data it stores. You may also need to map out how a SaaS ERP handles controls over accounting procedures, if that is necessary for compliance.

Getting SaaS compliant tends to be across-organizational process. Stakeholders from IT, security, audit, and legal need to get involved and collaborate. This is true for many areas of compliance, but with SaaS there is the added risk of business units arranging for SaaS on their own, without telling IT or security. The potential exists for accidental lapses in compliance due to such “shadow IT” situations. An open dialogue about SaaS compliance can avoid these risks.


Use of SaaS can affect compliance. SaaS apps may store data that’s subject to compliance rules, such as GDPR and EU residents’ private information. It is essential to know what data is being handled by SaaS vendors in your organization—and that they are able to pass compliance audits or certifications. Getting to success involves including SaaS in existing compliance preparation and audit processes, which may necessitate cross-organizational cooperation.

Haviv Ohayon

Co-Founder & COO

Back to list

The Top 3 SaaS Security Challenges

Software-as-a-Service (SaaS) applications present a number of potentially serious security challenges. The risks posed by SaaS arise out of a combination of factors. For one thing, SaaS is popular, with most businesses using dozens or even hundreds of SaaS apps in their operations. The depth and breadth of SaaS deployments make them hard to defend.

Image Credits: Suridata

SaaS is software, but its security parameters are different from those of traditional, on-premises software. A SaaS app is cloud-based, with access rights that are sometimes unclear. Third-party integrations can create vulnerabilities, as well. And, governance of SaaS apps can be spotty or nonexistent—especially when “shadow IT” takes over and business units purchase SaaS for themselves without notifying the IT department or their partners in cybersecurity. The article explores these issues and discusses the top three SaaS security challenges: access management, misconfigurations, and regulatory compliance.

1-Access Management

Access management is an essential element of any cyber security program. Indeed, managing who can access what is a fundamental control in all major cyber security frameworks. SaaS introduces some unusual challenges to access management, however. SaaS users can be anywhere, on almost any device. They can access the SaaS app, which may contain sensitive data, from outside the corporate network. These factors make it imperative that security teams and identity managers establish who is who, and what each user is authorized to do on the SaaS app.

User authentication, which is the verification of a user’s identity prior to granting access, can be challenging with SaaS. If a user tries to log in to a SaaS app, how can system owners be confident that it’s the real user, rather than an attacker impersonating the user? Multi Factor Authentication (MFA) is essential to reduce the risk of unauthorized access. Rigorous monitoring of identities is also a wise practice to stop malicious actors from gaining access to SaaS apps.

Third-party integrations create a related access risk. In some cases, plugins that connect one SaaS app to another make the plugin into an unmonitored “user” of the app. If an attacker takes over the plugin, which can occur easily when plugins are not maintained properly by developers, he or she can gain access to connected SaaS apps. 

Once a user has accessed a SaaS app, what is he or she allowed to do? This is a matter of authorization. Most SaaS apps enable multiple levels of access privileges. The more senior the user, the greater the access privileges, generally speaking. An executive user might be able to see all customer data, while a sales rep can only see his or her accounts. Administrative users may have the right to delete or export data, which makes their accounts attractive takeover targets for hackers. 

Geography is yet another aspect of SaaS access management. It is a good policy to restrict SaaS access rights by country or region. This will mitigate the risk of external threats to some degree, because hackers tend to be outside of the country hosting the SaaS app. There can be regulatory issues, too, with potential compliance risk arising out of users moving consumers’ private data out of its country of origin.  


Each SaaS app enables extensive custom configuration. This is usually a great benefit. Individual users can set up their SaaS apps the way they want them. Administrators can adapt SaaS apps to suit company-wide use cases and policies. The scope of configuration options, however, also creates security risk. 

Part of the problem is again, simply the scale of the SaaS estate in the average business. If a company has deployed a hundred SaaS apps (that it knows of), and each app has dozens of “knobs” users and admins can toggle for their specific configuration needs, the result is an environment with thousands of potential configurations. Any one of them could be insecure. Manual management is not a realistic option.

For example, some SaaS-based storage services enable universal file access by default. That means that virtually anyone in the world can access a company’s sensitive data on the Internet, without anyone even knowing. If users are not aware of this problematic default setting, data exfiltration risk will follow. 

A further difficulty comes from the frequency with which SaaS apps update themselves. While it is a great advantage to have an application that automatically makes new features available to users, this is also a driver of risk. A SaaS update might reset configurations to default, for instance. It will then be up to users and admins to set configurations back to match security policies—a task that is effectively impossible to perform thoroughly without automation.

3-Regulatory Compliance

SaaS apps can expose companies to regulatory compliance risks, which have a peculiarly synergistic relationship with security risks. For example, poor management of role-based access controls (RBAC) can result in breakdowns of “segregation of duties” controls needed for compliance with laws like Sarbanes-Oxley. Specifically, a segregation of duties control is supposed to do things like prevent a single user from being able to approve a purchase order as well as a payment to a vendor. Without the control, a user could commit fraud. 

If the company in question uses a SaaS-based accounting system, then it will be up to SaaS administrators to ensure that their access privileges they cover the segregation of duties control they need for Sarbanes-Oxley, e.g., User A is permitted to access the purchase order (PO) module of the software, but not the check approval module. User B is permitted to use the check module, but not the one for POs. This may not be a big problem, but given the breadth of SaaS configuration possibilities available, it’s an easy control to overlook.


SaaS can translate into security problems.Areas of risk exposure include access management, configuration, and regulatory compliance. Manual approaches to addressing these three areas of challenge are inevitably deficient. Intelligent, automated solutions are the best approach. With new SaaS security management tools, it is possible to stay on top of access, configuration, and compliance risks across even the broadest and most multi-faceted of SaaS environments.

Haviv Ohayon

Co-Founder & COO

Back to list

The Top 5 Third-Party Integration Risks

Businesses are embracing Software-as-a-Service (SaaS) applications with growing enthusiasm. The market for SaaS software has doubled over the last five years, from $85 billion in 2018 to $171 billion in 2022. Ninety-nine percent of companies use at last one SaaS application, though the average business uses 110, up 38% from an average of 80 apps the previous year. It’s easy to understand why SaaS is so popular.

Image Credits: Suridata

It’s easy to understand why SaaS is so popular. The technology frees customers from many of the total cost of ownership  of provisioning and supporting software and infrastructure. At the same time, SaaS also exposes its customers to new types of risk, especially from third-party integrations using SaaS plugins.

SaaS Plugins: What They Are and How They Work

A SaaS app typically works through a web browser. There is no software client required, and the data and application functionality occur in the cloud. Most SaaS apps allow third-party vendors to build plugins that provide additional capabilities to the SaaS.

For example, a customer relationship management (CRM) SaaS app might allow plugins from productivity suites like Microsoft 365 or Google Workspace. In these SaaS-to-SaaS integrations, data from the CRM can flow directly into the productivity suite, e.g., automatically updating an email address in the CRM from the latest data in the productivity suite.

For the plugin to work, the SaaS user has to grant permissions to the third-party plugin. The plugin acts on behalf of the user within the SaaS app, a capability made possible through the use of authentication tokens. 
This has ramifications for security. The third-party plugin, built by a developer who has nothing to do with the CRM app, can gain access to its data and operate on behalf of the user.

Why SaaS Plugins Can Be a Source of Risk

SaaS plugins expose their users to cyber risk. There are a number of reasons for this, but the foundational problem has to do with how SaaS plugins act on the user’s behalf. The SaaS app sees the plugin as the user. 

Permissions and configurations are another source of security trouble with SaaS plugins. A plugin can require the user to agree to a wide scope of permissions that are not really needed for the plugin to do its job. This can be for reasons ranging from developer laziness to malicious activity.

For instance, a customer service representative might have access privileges that allow him or her to see customers’ tickets, financial transactions, customers’ credit histories and the like. There presentative can have a pre-installed SaaS plugin, installed by the admin, for sending email notifications whenever new tickets are opened. Yet, the plugin asks for far broader data access than just the tickets status. This is almost always not a deliberate choice, but rather an administrative oversight. Given that the average organization has 110 SaaS apps running, it’s not hard to see how admins could make this kind of mistake. 

Going further, if SaaS users are allowed to install plugins on their own, and/or grant access to any plugin they want, they may install malicious plugins or legitimate ones that have no business need for the company. This is a security policy issue, but one with potentially serious repercussions. 

It may be a surprise to some that a SaaS plugin can be malicious. Aren’t they “official” plugins if they are available at the SaaS app’s store? One might be surprised at the vulnerabilities embedded in plugins that are available for easy download and installation. In fact, not all app stores properly scrutinize the plugins uploaded to them. It could be a simple case of abandonment. If the plugin-vendor no longer supports the plugin and updates it with security patches, the plugin will soon become a source of risk. Or, some untrustworthy party buys a once-legitimate plugin and modifies it, perhaps maliciously, and the end-client has no knowledge of the change.

The Top 5 Risks From SaaS Plugins

With these factors in mind, consider the potential impacts that a malicious plugin could have on a business. Here are the top five risks:

1.  User impersonation — If an attacker can convince a user to install a malicious plugin to its SaaS, they can than act within the SaaS as the user itself.  He or she can impersonate that user and interact with other employees or even customers, while impersonating the user. They may view sensitive data, perhaps taking advantage of overly generous permissions in the process, and manipulate data, delete it, or steal it. 

2.  Data breach — A SaaS plugin can form the attack path for a data breach. With access to the SaaS via the plugin, the attacker controlling it can exfiltrate data through it.

3.  Business disruption — If a SaaS plugin is vulnerable to a take over, it can be commandeered by hackers and made into a vehicle for accessing the SaaS data. This can be disruptive to the SaaS customer, potentially even threatening to shut down their operations until the attack can be mitigated. 

4.  Abuse of resources — SaaS applications are not cheap, so an attacker might want to take advantage of free, improper access to perform tasks like data analytics or file storage on the SaaS customer’s account. 

5.  Compliance Risk — A data breach can lead to compliance penalties if, for example, it results in violations of privacy laws. A compliance audit that reveals deficient controls over SaaS access can also trigger problems for companies that need to comply with frameworks like NIST CSF, SOC 2 and so forth.

Addressing Third-Party Integration Risk From SaaS Plugins

It is possible to reduce third-party integration risk from SaaS plugins. Suridata, for example, provides deep visibility into SaaS application risk, including automated monitoring of SaaS plugin permissions. The solution can identify third-party integration risks and automatically remediate them with workflows that orchestrate the complex steps required to make SaaS plugins safe.


SaaS apps, which are becoming increasingly popular due to their favorable IT economics and ability to speed up adoption of useful software, expose companies and users to cyber risks. SaaS plugins, in particular, create third-party integration risks. Attackers can exploit excessive permissions and malicious or out-of-date plugins to impersonate users and perpetrate data breaches, among other negative security impacts. Solutions are available however, that can automatically scan SaaS plugins for security weaknesses and then provided automated remediation.

Haviv Ohayon

Co-Founder & COO

Back to list