The trend in the pharmaceutical industry is also moving towards cloud computing. Financial but also organizational advantages speak for the cloud. At the same time, however, potential dangers and regulatory restrictions should also be taken into account. Nine experts from the pharmaceutical industry and regulatory authorities answer a comprehensive catalog of questions from the following GxP-relevant topics:
Basics of Cloud Computing Technology
Regulations and Expectations of Inspectors
Requirements for Cloud Service Providers (CSP)
Requirements for Supplier Evaluation and Supplier Audits
Requirements for Qualification / Validation
The following question is one of a series of questions that we will publish in further GMP News articles on this site in the coming weeks.
Question 16: What are the consequences of the different service models (IaaS / PaaS / SaaS / XaaS) for supplier management and the related qualification / validation?- Requirements for Qualification / Validation.
As described in "What's the meaning of IaaS / PaaS / SaaS / XaaS?" (see Q1), the major differences in service models regarding qualification and validation lie in the shift between the supplier's (Cloud Service Provider, CSP) and the user's (regulated company) responsibility. Special cases like HPCaaS or AIaaS (see "What's the meaning of IaaS / PaaS / SaaS / XaaS?") are handled like SaaS to keep it simple, i.e., we are looking at IaaS, PaaS, and SaaS only.
It is important to note that the responsibility of the regulated company regarding patient safety, product quality, and - especially noteworthy in the context of cloud computing - data integrity cannot be delegated to a CSP or any other service provider!'
However, cloud models are perfect examples for leveraging: "Build on top of your service provider's outputs and achievements!". Thus, the qualification and validation activities to be performed by the regulated company are geared by the service model (plus the usual suspects like GxP relevance, risk, novelty, complexity etc.):
IaaS: The CSP provides the infrastructure only. As configuration and operation of all other layers are handled by the regulated company, specific additional measures are not required. To minimize risk, we recommend requesting a minimum availability of the infrastructure and define a plan B to continue operation in the case it is "down" (the latter is recommended for infrastructure operated by the regulated company, too).
PaaS: The CSP provides the infrastructure and installs the operating system. As operating systems fall into GAMP software category 1 and are - at least for all common operating systems - considered to be of low risk, the recommendations for IaaS apply here as well. As an additional risk control, the operating system's configuration should be specified and verified. Furthermore, the regulated company should understand how and how often the CSP updates the operating system and when and how the regulated company is being notified. The update procedure should be defined in an SLA.
SaaS: The CSP provides the infrastructure, the operating system, and the application. Here, the CSP needs to specify and verify the application according to the regulated company's requirements and standards. Furthermore, some aspects of configuration control stay with the CSP. This model requires solid trust, often underpinned by a risk-based assessment and evaluation of the CSP, typically supported by an audit. The overall risk as well as the assessment scope can be reduced if the CSP provides relevant documentation like certificates or White Papers. Risks identified as result of the assessment should be mitigated by commensurate control measures, e.g. SLAs. The CSP's update strategy is even more important for SaaS (than for PaaS), as changes and updates may have wider impact and carry more risk. Therefore, understanding the CSP's update strategy and being notified about any planned and upcoming changes is even more relevant.
No matter whether IaaS, PaaS, or SaaS: The roles and responsibilities of both, CSP and the regulated company, should be clearly defined and any procedures for updates and change control should be contractually agreed.