Security and IT leaders are concerned about the speed and ease with which employees can bring SaaS applications into the business environment. 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.
Yet, employees often have legitimate reasons for using such apps for wanting to use such apps. What are we to do to support the use of SaaS within the enterprise, but do so in a responsible way?
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.
Nowadays, employees can sign up for SaaS applications without involving anyone in the company. 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 the 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.
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:
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.
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:
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.)
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.
Click to Open Code Editor