Using SaaS in a Regulated Environment – A Life Cycle Approach to Risk Management
1 Introduction
In the evolving regulated IT environment there are many things to consider when thinking of turning to the cloud for a solution. This Concept Paper describes issues and risks to consider when establishing a reliable, secure, and economically sound relationship with the SaaS provider. These risks have been divided per relationship stage with some practical process controls offered to mitigate those. While it is not universally true, SaaS providers delivering specialized support to regulatory business processes (e.g., Clinical Trails, Release Testing, AE reporting) tend to have a good understanding of the needs of regulated companies.
Using a SaaS provider can be an excellent option for regulated companies, but doing appropriate research and identifying the company’s specific support needs are critical to making the right choice of SaaS provider. Those needs/requirements should be assessed across the entire span of the relationship with the SaaS provider, rather than just meeting the immediate need of the end user.
Internal IT relationships within pharmaceutical organizations have been long established and consist of reviewing current performance and planning long term IT road maps to support the business. Whenever business requirements change, it is expected that an internal IT department will adjust their service offering accordingly. This internal relationship is determined by organizational structure, and guided or controlled by internal Operational Level Agreements (OLAs)/Service Level Agreements (SLAs).
In contrast, SaaS providers are likely to be serving multiple customers; therefore they may not be able to adjust their service “on demand”, e.g., introducing a new software feature for a single customer would not make much sense if others do not need it. The relationship with the SaaS provider is driven by the duration and content of the contract. Changing an internal agreement is always easier than changing an external contract and this limitation should be taken into consideration.
There are also advantages that the use of SaaS providers has over maintaining large internal IT departments. SaaS providers allow regulated companies the opportunity to select a service offering that best suits them both as users and for their budget. In addition, the use of SaaS providers also provides the ability to exit the relationship if the service is no longer needed or not adequately provided. The regulated company should consider the beginning, middle, and end relationship before engaging the SaaS provider, in order to take full advantage of the engagement of the SaaS provider and to mitigate any accompanying shortcomings. This Concept Paper discusses risks during three phases of this relationship and has labeled these phases as the:
- Concept Phase
- Operational Phase
- Retirement Phase
2 Relationship to the GAMP® 5 Model
The GAMP® 5 phases apply to SaaS cloud applications, but need to be shifted when compared to in-house delivered and maintained systems. The shift is a result of when an application is considered “productive” versus “in production”. The in-house developed application is classically referred to as “in production” when the application is deployed to the end user in support of the business process, as described by the GAMP® 5 model and reflected in blue in Figure 2.1. These applications, by virtue of being “in house” will leverage the corporate security and privacy framework through the Project and Operational phases.
Figure 2.1: GAMP® 5 Model and SaaS delivery
In addition, the GAMP® 5 Concept phase typically needs to be expanded for SaaS scenarios to ensure that a vendor selection process and a corporate strategy are established. Ideally, the cloud strategy and vendor selection processes should already exist and be leveraged by individual projects. However, if not established at a corporate level, a team will (as part of a project) need to ensure that the vendor and solution is suitable for the intended scope and application of the project. This is also the point where the Project and Operational phases of the GAMP® 5 model will likely start and overlap (see Figure 2.1).
In order to ensure that a vendor’s SaaS offering will meet a business process, Proof of Concepts (POCs) or pilots are typically undertaken prior to a final vendor decision. The moment that the SaaS system is attached to a corporate network, or data is placed with the SaaS provider, the system can be thought of as operationally “project ready”. Elements such as change management, security monitoring, access management, and communication of incidents at the vendor site should be established, in the same way as for an “in house” project. Once a system is “project ready”, the regulated company will have to rely on the SaaS provider’s security and privacy frameworks.
SaaS systems can be thought of having two transitions to an Operational phase:
- The first transition is when the system is accessible by the regulated company for purposes of POCs or configuration.
- The second transition is when the system is made available to the end user to support the business project.
2.1 Concept Phase
The activities and considerations of the Concept phase should occur prior to engaging with a SaaS provider and should be performed by a regulated company in order to enable adequate planning of delivery activities. Phases labeled as Operational and Retirement phases of the relationship describe potential risks and issues that should be
considered during what would map to the traditional GAMP® 5 life cycle phases.
A company should develop a could strategy that includes the classification of business processes that also accommodates the data and potential risks to product quality and patient safety, as well as data integrity. Consideration should be given to the overall architecture of the information landscape of the regulated company’s long-term integration needs. Audit and contractual needs should be established to assure control over providers and any sub-contractors, in order to facilitate necessary company and vendor interactions in subsequent phases.
It should be noted that some suppliers offering public cloud and multi-tenancy solutions may be less likely to be interested in being audited by regulated industry customers. In some senses this means the regulated company may face a “take it or leave it” attitude. If the supplier’s current standard controls are not what are needed for regulated applications and data, a company may have to look elsewhere, or institute additional controls of its own. Additional controls by a regulated company may be of only limited effectiveness when considering SaaS solutions.
There should be a clear understanding of the processing and hosting landscape of the future solution to ensure that security and privacy risks are addressed.
Read more by downloading Using SaaS in a Regulated Environment – a Life Cycle Approach to Risk Management (Published: July 2016).