SaaS in the Real World: Who’s Responsible to Secure this Data?
When SaaS applications started growing in popularity, it was unclear who was responsible for securing the data. Today, most security and IT teams understand the shared responsibility model, in which the SaaS vendor is responsible for securing the application, while the organization is responsible for securing their data.
What’s far murkier, however, is where the data responsibility lies on the organization’s side. For large organizations, this is a particularly challenging question. They store terabytes of customer data, employee data, financial data, strategic data, and other sensitive data records online.
SaaS data breaches and SaaS ransomware attacks can lead to the loss or public exposure of that data. Depending on the industry, some businesses could face stiff regulatory penalties for data breaches on top of the negative PR and loss of faith these breaches bring with them.
Finding the right security model is the first step before deploying any type of SSPM or other SaaS security solution.
Learn how Adaptive Shield’s SSPM solution can help secure your SaaS stack.
Getting to Know the Players
There are several different groups of players involved in the SaaS security ecosystem.
SaaS App Owners – When business units subscribe to SaaS software, someone from within the business unit is typically responsible for setting up and onboarding the application. While they may have some help from IT, the application is their responsibility.
They choose settings and configurations that align with their business needs, add users, and get to work. SaaS App Owners recognize the need for data security, but it isn’t their responsibility or something they know very much about. Some mistakenly assume that data security is only the responsibility of the SaaS vendor.
Central IT – In most large organizations, Central IT is responsible for things like infrastructure, hardware, and passwords. They manage IDP and servers, as well as oversee help desk activities. SaaS applications typically do not fall under their direct domain.
Central IT is more familiar with security requirements than the average employee, but it isn’t their primary concern. However, it is important to keep in mind that they aren’t security professionals.
Security Teams – The security team is the natural fit for implementing security controls and oversight. They are tasked with creating and implementing a cybersecurity policy that applies across the organization.
However, they have several challenges inhibiting their ability to secure applications. For starters, they are often unaware of SaaS applications that are being used by the company. Even for applications that they are aware of, they lack access to the configuration panels within the SaaS stack, and aren’t always aware of the unique security aspects associated with each application. Those are controlled and maintained by the SaaS App Owners and Central IT.
GRC Teams – Compliance and governance teams are tasked with ensuring that all IT meets specific security standards. While they don’t play a specific role in securing corporate assets, they do have oversight and need to determine whether the company is living up to its compliance responsibilities.
SaaS Vendor – While the SaaS vendor is absolved from any responsibility to secure the data, they are the team that built the security apparatus for the SaaS application, and have a deep knowledge of their application and its security capabilities.
Defining Roles and Responsibilities
Securing the entire SaaS stack requires close collaboration between the security experts and those managing and running their individual SaaS applications. We developed this RACI chart to share our perspective on the departments that are responsible, accountable, consulted, and informed for the different tasks involved in securing SaaS data.
Bear in mind, this table is not one size fits all, but a framework based on the way we see many companies handling their SaaS security roles. It should be adapted to the needs of your organization.
Learn more about SaaS user roles and responsibilities. Schedule a demo today.
Building the Right Infrastructure
Developing the RACI matrix is important, but without the right tools in place, implementing security responsibilities becomes a near-impossible task.
Organizations need a SaaS Security platform that facilitates clear communication between the security team and app owners. This communication should include alerts when misconfigurations occur that weaken the individual app’s security posture and when threats are detected by its IAM governance tools.
Communication should be channel agnostic, so users can receive messages and alerts over email, Slack, Splunk, or the messaging platform of choice. All security-related notifications should also include remediation steps, providing app owners and central IT with a clear understanding of the steps required to mitigate the risk.
Within the platform, each owner should have visibility and access to the app or apps under their control. They should be able to see the status of their security settings, their security score, their users, third-party SaaS applications that are connected to their app, and the devices being used to access their SaaS app.
App owners and central IT should also have the capabilities to dismiss a security alert due, either because it doesn’t apply or due to business needs, and consult with the security team on risk.
Securing SaaS Data Takes a Cross-Team Effort
It’s easy for SaaS application security to be overlooked. It sits outside the view of the security team and is managed by competent professionals whose responsibilities don’t include security.
However, the data contained within the SaaS applications are often the lifeblood of an organization, and failure to secure the data can have disastrous consequences.
Fully protecting the data from exposure requires a cross-team effort and commitment from all parties involved, as well as a sophisticated SSPM platform built for SaaS in the real world.
Learn how an SSPM can help secure your data. Book a demo.