Before SaaS, employees had to rely on IT and other teams to procure software, which gave the organization a direct way of controlling such purchases and deployments. Now, employees can sign up for SaaS applications without involving anyone in the company. All it takes is a few clicks and (sometimes) a credit card for people to start using such products. In moments, SaaS apps can start processing sensitive business data with no consideration for security, governance, oversight, and other requirements that are at the top of the minds of CISOs and CIOs.

The lack of internal bottlenecks empowers people to quickly get the tools they need to get work done. However, finance, IT, Legal, and other teams lack the visibility to ensure that SaaS apps are provisioned and managed responsibly and securely. No longer the gatekeepers, these teams must revisit the approaches to guiding and overseeing the company’s use of SaaS.

What can we do to support the use of SaaS within the enterprise, but do so in a responsible way?

Security, IT, and SaaS "Ownership"

There are several reasons why SaaS ownership is challenging for IT and security teams.

Employees can start using SaaS applications without any involvement from IT and security teams. As a result, these teams are often unaware that the applications are being used and don’t know about their associated risks. For example, we might not realize that a SaaS provider now processes sensitive data and cannot associate the appropriate security measures with the app. On their own, end-users often lack the expertise to configure the apps in a way consistent with the organization’s policies. 

Another challenge is the lack of a clear understanding of the roles and responsibilities of “owning” a SaaS application:

• Who is responsible for adding new users to it and assigning them the appropriate permissions?
• Who will revoke access when the need arises?
• Who will handle renewal and other licensing discussions?

End-users who initially purchase a SaaS product might expect IT or other teams to handle all or some of these responsibilities, but these teams might not share this understanding.

In addition, modern SaaS applications rarely function as data siloes. They often integrate with other software. The individuals who bring SaaS into the organizations often do not consider such interdependencies and dataflows. Late-stage discovery of such externalities can put unexpected burdens on IT and security teams and might prevent the SaaS application from achieving its full potential in a reasonable timeline.

Clarifying SaaS Expectations

IT and security teams should document the roles and responsibilities of deploying and maintaining a SaaS application. Explain what aspects of the IT team will own the app’s configuration and oversight. We should clarify what responsibilities might reside with the end-users. For example, depending on how the app integrates with the company’s identity management system, IT can automatically provision users with the proper privileges into the SaaS app; in other cases, designated people outside IT might need to do this.

Also, we should clarify the company’s expectations of SaaS applications:

• What security requirements does the organization impose on its SaaS providers?
• How might these requirements differ based on the sensitivity of the data they process?
• What are the service-level expectations, Single Sign-On (SSO) requirements, etc.?
• What other internal teams, such as Legal and Finance, might need to be involved and when?

We should document these expectations so that people looking at SaaS know what they need to do or communicate to SaaS providers.

In addition, we should recognize that unsanctioned SaaS products will find their way into the organization. Consider what approaches and tools we might use to discover their existence, so IT and security teams can bring the necessary oversight to their usage to protect the organization and support end-users. (Axonius, where I lead the security program, offers a solution for this.)

Collaborating with SaaS Stakeholders

One way to start the discussion of SaaS ownership is to identify common interests. Most likely, all stakeholders want to have a SaaS application that is correctly deployed and properly licensed. It should be available to the right people with the expected functionality. The stakeholders will probably agree that the app should be responsibly secured and not expose the organization to unexpected or undesirable risks.

Next, we can outline what one-time and ongoing tasks should happen for the organization to meet the identified objectives. With these responsibilities at hand, we can discuss who is best positioned to handle them, how, and when. We can also assign responsibilities according to the RACI model, which calls for agreeing on who should be responsible, accountable, consulted, and informed about the tasks.