Question 1: What does Iaas/PaaS/SaaS/XaaS mean?

IaaS, PaaS, and SaaS are abbreviations and different tiers (or service models) of various cloud service provider (CSP) offerings. "AaS" always stands for "as a service". In XaaS, X is a placeholder for I, P, or S, representing infrastructure, platform, or software. Sometimes, XaaS is also referred to as "Anything as a Service" or "Everything as a Service" and can have very specific characteristics, such as "high performance computing as a service (HPCaaS)" or "artificial intelligence as a service (AIaaS)".

The CSP provides various services and benefits based on the basic service model, and the tasks to be performed may vary accordingly, as shown in the following table:

n For computerized systems or applications that traditionally run locally, the regulated company (or its IT department or IT service provider, if outsourced) is responsible for all tasks related to computerized system verification (CSV).

nIaaS: If the infrastructure is provided and managed by a CSP, the model is called IaaS. Here, the tasks and responsibilities of the regulated company begin with the installation of the operating system.

n At the next level, the CSP takes over the installation and operation of the infrastructure and operating system. A regulated company is involved in the configuration of the runtime environment.

nSaaS: For this model, the CSP provides and operates the configuration of the runtime environment and applications on top of the infrastructure and operating system.

In other words, the activity shifts from the user (the regulated company as the customer) to the cloud service provider (vendor). However, the responsibility for the verification and operation of the application and all related topics such as data integrity, data privacy, data security, etc. remains with the regulated company.

Question 2: What are the cloud models and what are their applications in a GxP environment?

Basically, there is no uniform specification for the classification of cloud models. NIST (National Institute of Standards and Technology) has developed a so-called "deployment model", which describes a widely used classification (The NIST Definition of Cloud Computing,Special Publication 800-145, September. 2011):

n Private cloud: In a private cloud, the cloud infrastructure is run by only one organization. It can be organized and managed by the institution itself or by a third party, and can be located in the institution's own data center or in a third-party institution.

Public cloud: We call it a public cloud if the service can be used by the public or a large group (e. g., an entire industry sector); these services are provided by the corresponding cloud service provider at its facility/data center.

n Community Cloud: In a community cloud, the cloud infrastructure is shared by multiple agencies with similar interests (e. g., in security, compliance). Such a cloud may be operated by one of these institutions or a third party.

n Hybrid cloud: When multiple independent cloud infrastructures are shared through standardized interfaces, it is called a hybrid cloud.

In a private cloud, the provider and the user are usually the same, and the user can fully control the services used, while in a public cloud, the user transfers control to the cloud service provider. However, the above definition does not cover all variants of cloud services, so further definition is needed, such as "virtual private cloud. Another common difference in cloud models is the classification by "service model" (SaaS, PaaS, IaaS)-see question 1.

Basically, all "deployment models" or "service models" are also used in GxP-regulated industries. Here, the choice of cloud model is mainly based on the criticality of the GxP process supported by the cloud service and the data processed in the process. For example, the tools that support the training process, the so-called learning management systems (LMS), are often licensed as public clouds. In contrast, very critical applications, such as the management of trial master files, run at most within the framework of the community cloud service.

Regardless of the importance of the process and data, the specific characteristics of the supported process support the use of community or private cloud products: the more specialized the process (for example, maintaining a tracking master file), the smaller and more specialized the group of potential subscribers.

Question 3: What are the reasons for choosing a specific cloud model (private cloud, community cloud, public cloud)?

In addition to commercial reasons (not discussed further in the context of GxP-regulated applications), practical reasons usually play a role in the choice of cloud model. In particular, small companies with relatively limited IT resources tend to use cloud services that they cannot provide with their own resources. This may be because they do not have enough human resources to provide all the topics required, or because they simply do not have the necessary expertise (technology related to the process, data security).

In the GCP world, the special conditions prevailing there also promote the use of cloud services for very practical reasons: clinical trials are shared with many parties (hospitals, doctors, CMOs, sponsors), often globally. Moreover, the composition of the parties involved is not a fixed group, but is subject to change. The cloud service is universally accessible via the Internet, supports this way of working, and is designed for 24x 7 operation due to its international positioning.

Another factor to consider, especially when choosing a cloud service, is the security requirements of the GxP process supported by the system. In Annex 11, pharmaceutical companies are explicitly required to align the required safety measures with risks (EU GMP Annex 11[12.2]: "The degree of safety control depends on the criticality of the computerized system)".

This may mean that particularly sensitive data should generally not be processed in the public cloud for reasons of GxP data integrity. This decision-making requires the cooperation of all professional disciplines (IT, process owners, QA) to achieve a well-thought-out, technically sound risk assessment. This especially requires in-depth IT expertise because the topic of "data security" can be very complex (nesting of cloud services, redundancy across multiple data centers, authentication providers used, etc.) and can change permanently.

If the business processes supported by the computer-based system place high demands on the availability of data and functions, this may have a direct impact on the applicability of cloud-based services:

n Whether it is an additional reliance on an Internet connection or a "local" implementation that claims to be accessible via LAN;

n While a highly redundant design across multiple regions and ease of horizontal scaling are critical for using cloud services, rather than installing on a local network.

Especially in the field of GCP, data protection requirements (for example, personal data in clinical trials) play a vital role. Therefore, data protection determines whether the required cloud services are considered, and if so, in which country the data center used must be located.

Even if this is not based on GxP requirements, high requirements for confidentiality of sensitive data (e. g., data from clinical research or product development) can determine whether to consider cloud services or restrict cloud services.

Question 4: Is the SaaS closed system compliant with 21 CFR PART 11?

The terms SaaS and "closed system" are not related, I .e. one neither implies nor excludes the other. First, SaaS is a service model for providing software applications in the cloud (I. e. over the Internet) by cloud service providers (CSPs). This requires data to be transferred, at least temporarily, to the cloud where it is stored and processed, often permanently.

On the other hand, the definitions of "open" and "closed" systems do not refer to the manner in which data or applications are provided, but rather define the expected level of control. This control of data and applications is mainly achieved through operational and technical measures related to access protection, user identity and rights management, and encryption. Therefore, the level of control is not independent of SaaS, but represents a different dimension.

In § 11.3 (B)(4), 21 CFR PART 11 defines a closed system as "an environment in which system access is controlled by the person responsible for the content of electronic records on the system". In contrast, § 11.3 (B)(9) defines an open system as one that lacks such control. Therefore, closed and open systems have very different measures such as verification and data privacy, which are defined in detail in paragraphs § 11.10 and § 11.30, respectively.

As a result, each SaaS-provided application may be an open system, but typically operates as a closed system, especially when dealing with critical, sensitive, or trusted data (typically: data worth protecting).