This article briefly discusses what Cloud Computing is and is not, and addresses some of the challenges to validating enterprise applications that are either managed/hosted by a third party or that are genuinely ‘In the Cloud’.

Terminology in the article is based on the NIST definition of Cloud Computing contained in NIST SP-800-145 and the text of the article is taken from Chapter 17 (“Validating Enterprise Applications in the Cloud”) of “Validating Enterprise Systems: A Practical Guide”, with the permission of the author and publisher PDA

Use this link to purchase a copy of the book.

Hosting and Managed Services versus ‘The Cloud’

As defined by NIST, Cloud Computing has essential characteristics which are defined as:

  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured Service

While many hosting and managed services companies meet a number of these characteristics (i.e. broad network access via the Internet, resource pooling via scalable architectures and provision of a measured service via a suitable Service Level Agreement) many do not provide an on-demand service (“A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider”) and rapid elasticity (“Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in.”).

It is the ability to quickly scale the use of the enterprise application (e.g. to add additional processing resources at a month end financials close, or quickly add hundreds of new sales users to a CRM system with no degradation in performance) that differentiates traditional hosting and managed services from true Cloud Computing.

The ability to provide on-demand self-service brings potential risks to the validated state of a hosted enterprise system. While the service provider may provide on-demand self-service the Regulated Company nevertheless retains accountability for effective change control of the application and any requests made of the service provided should go through an internal change control and authorization process.

Rapid elasticity may also pose problems if changes to the underlying Infrastructure are made with insufficient control. While the technology allows additional memory, processors, disk space to be rapidly allocated and de-allocated it is important that this is controlled and that the service provider has suitable change control, configuration management and infrastructure qualification process in place to maintain control.

On-Premise versus Off-Premise Deployment Models

Cloud Computing has five different deployment models as follows:

  • Private cloud
  • Community cloud
  • Public cloud
  • Rapid elasticity
  • Hybrid cloud

Private Cloud

The Private Cloud is specific to the Regulated Company and the cloud infrastructure is operated solely for the Regulated Company. It may be on-premise (in the Regulated Company’s data centre, provisioned by their own IT staff or a third party) or off-premise (at a third party site, provisioned by that third party). The dedicated nature of the Private Cloud and the one-to-one relationship between the Regulated Company and the provider means that it is easier to exercise effective accountability and to validate the enterprise application with few additional risks to consider. Almost any enterprise application is suitable for provisioning via a Private Cloud.

Community Cloud

With a Community Cloud, the cloud infrastructure is shared by several organizations (typically Regulated Company’s) and may again be on-premise or off-premise. If all the organizations are Regulated Companies it should be possible to exercise suitable accountability even when the enterprise application may be provisioned and managed by a third party on behalf of the community. The Community Cloud supports a specific community that has shared concerns and examples of enterprise applications in the Community Cloud may be a web portal application used by multiple business units within the same Regulated Company, a collaboration website used by a clinical trials sponsor and multiple CROs or a system providing prescription data to subscribers via the Internet.

Public Cloud

In a Public Cloud the cloud infrastructure is also made available to the general public or a large industry group and is owned by an organization selling cloud services (off-premise). This typically means that Regulated Companies are sharing the Cloud with non-regulated users and this can be a source of additional risk where the provider does not fulfil the specific requirements of the Regulated User in terms of staff training, infrastructure qualification, applications validation etc.

This needs to be rigorously reviewed as part of a supplier audit and it should be noted that a supplier assessment with no on-site audit is usually insufficient to justifiably place GxP significant applications into the Cloud. Part of the attraction of Cloud Computing to most users is that it is not necessary to understand the underlying

IT Infrastructure, where applications are running and where data is located. Regulated Companies are however still accountable for the validation of their applications and the integrity of their data and understanding how the Cloud Services are provisioned in a Public Cloud deployment model will require a thorough supplier assessment and an audit to ensure that processes and procedures are being followed.

Hybrid Cloud

A Hybrid Cloud deployment model is a composition of two or more clouds (private, community, or public) that remain separate entities but which are bound together by technology, thereby enabling data and application portability. Where a Hybrid Cloud combines a Public Cloud the same issues need to be considered.

Infrastructure, Platform and Software as a Service (IaaS, PaaS and SaaS)

Cloud Computing may also be provided following one of three service models:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS).

When many people think about Cloud Computing they usually think about Software as a Service and this is certainly the obvious model when thinking about enterprise systems.

With Cloud Software as a Service the capability provided to the Regulated Company is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser and the Regulated Company does not manage or control the underlying cloud infrastructure (there may be the possibility to make limited user-specific application configuration setting changes.

In a Cloud Platform as a Service model, the capability provided to the Regulated Company is the ability to deploy their own enterprise application(s) onto the cloud infrastructure provisioned by a third party. The Regulated Company still does not manage or control the underlying cloud infrastructure (including network, servers, operating systems, or storage), but has control over the deployed enterprise systems and possibly the application hosting environment configurations.

Finally, in a Cloud Infrastructure as a Service model the capability provided to the Regulated Company is the provisioning of processing, storage, networks, and other fundamental computing resources. The Regulated Company is able to deploy and run arbitrary software, which can include operating systems and applications. The Regulated Company still does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

In all three models, as for general hosting services, the service provider should qualify and exercise effective control over the IT Infrastructure. Note that the Life Sciences general definition of IT Infrastructure includes both IaaS and PaaS models. Controls for IT Infrastructure qualification should follow the principles described in Chapter 13. Appropriate support and maintenance process should also be established as described in Chapter 20. While many providers operate first class facilities which address key concerns such as physical and logical data security, service levels, maintenance and support processes there are common areas of weakness which should be reviewed in detail during a supplier audit are:

  • Regulatory awareness training for staff (the Regulated Company may have to provide such training),
  • The establishment of a formal QMS based on recognised standards (e.g. ISO 9001:2008, ITIL etc.),
  • The formal verification of infrastructure build and installation as part of a defined infrastructure qualification process.

Software as a Service Issues

With specific focus on Software as a Service there three key issues that need to be considered to ensure the regulatory compliance and validation of the enterprise system. These are:

  • The ability of the application to provide regulatory compliant functionality
  • The security of a multi-tenanted system
  • The ability to validate the application.

As defined above, in many SaaS models the Regulated Company has little or no ability to change the functioning of the enterprise application. This may mean that key functions do not work in a way that supports the Regulated Companies interpretation of the applicable regulations. While this may not be an issue for enterprise applications which are specifically focused in Life Sciences (e.g. Clinical Trials Management Systems, LIMS, CAPA) this may be a considerable issue for more generic applications such as ERP, CRM, MES etc.

The Regulated Company must therefore:

  • Clearly understand their own requirements, based on their interpretation of the applicable regulations
  • Understand the functioning of the SaaS enterprise system. This will usually require detailed demonstrations
  • Understand to extent to which they may be able to configure the system to meet their specific needs.

If a functional gap still exists it may be possible to take one of two options:

  • Use manual processes or other systems to meet the regulatory requirements not provided by the system
  • Deploy a compliant enterprise system using a PaaS or IaaS model (where the Regulated Company still has the ability to configure the application, usually as a Private Cloud deployment model).

With respect to security and data integrity, most true SaaS applications are multi-tenanted, meaning that multiple organizations use the same instance of the application and that multiple users’ data may be contained in the same database.

Enterprise systems developed to run a true SaaS application have generally be designed to provide good levels of security to prevent users from seeing each other’s data. Good database models also means that Regulated Companies should be able to archive and copy their data and records, which are important regulatory requirements which should be evaluated during a supplier audit.

This may not be the case for older enterprise applications which were not developed for true multi-tenancy and it is important to understand whether the application was designed for multi-tenancy or whether the provider is relying on user profiles, security matrices and database security which were not architected with multi-tenancy in mind.

A well architected multi-tenancy application should have been tested by the service provider and Regulated Companies should review this testing. If these testing did not take place (or if the provider is unwilling or unable to provide evidence of the testing) the Regulated Company may need to perform additional security testing. If the security of the application and database is inadequate it may still be possible to leverage the same application running as a Private Cloud single instance in a PaaS or IaaS service model.

Related: Train Your Staff on Risk Based Equipment Qualification

If functionality and security of the SaaS enterprise system are acceptable it is then necessary to validate the application and it may be possible to leverage the work of the service provider. With a defined and relatively fixed functionality it is possible that the provider will have good documentation defining market requirements, functional requirements, design specifications, software development and multiple test cycles.

If this is the case the Regulated Companies job of validation is much easier and validation documentation can be written to leverage the provider’s documents. It will also be necessary for the Regulated Company to document an assessment that the standard system functionality meets their specific business requirements (this is a part of the Eudralex Volume 4 Annex 11 guidance).

While this may not require the creation of full User Requirement Specifications the process by which the standard enterprise system functional was verified should be documented e.g. the scope of the demonstrations, the version of the software reviewed and the user representatives involved should all be recorded and the users should be required to sign off on the fact that the software fulfills their user requirements.

Where the providers test documentation cannot be relied upon (because the level of test documentation and evidence is insufficient) or is not available the Regulated Company will need to conduct User Acceptance Testing of the application. This may also need to be repeated each time the SaaS provider releases a new version, a process over which the Regulated User has little or no control.

This can happen very frequently with fast changing SaaS applications and if the providers test processes and documentation cannot be relied upon this can because burdensome to the Regulated Company. It should also be noted that while the providers own testing may be executed in a separate Test/QA environment most SaaS providers do not make a separate Test/QA instance to their consumers.

This challenge is best-handled as follows:

  • Where practical, automated software test tools should be used to perform extensive functional and regression testing for every release to or upgrade of the SaaS application. Where releases are very frequent the use of automated test tools allows this to be done every day. Note however that frequent changes to functionality also means that automated test scripts may need to be updated
  • Manual functional testing can be carried out, but this this is time consuming. It may be possible to note when a new release is made and gradually test each function over a period of time, formally recording the execution of processes and transactions as they occur in support of everyday operations i.e. use the execute the live transaction as a formal test. It may however take a significant amount of time to test every normal, alternative and exceptional User Case and a new release may occur before full functional testing is complete. This approach requires significant tracking and management.
  • Where testing does occur in the production environment there is a risk that data generated by testing remains in the production database. This can be an issue where alternative or exceptional Use Cases can appear to have manufactured an out of specification batch or where a production design was taken back into development. This is best handled by either or both of the following options:
  • Conducting testing at a time when the Production Instance was not being used for live operations e.g. at night or at the weekend. Such transactions can therefore be recognized by their time stamp,
  • Using defined test master data which clearly identifies the transaction as a test e.g. product code = TESTPROD1, recipe = TESTREC1, customer = TESTCUSTn etc.

Whichever approach is used it is essential that there is a robust Incident and Problem Management process in place to identify any issue caused by a new release and that these processes are closely integrated with the SaaS providers processes.

Ideally a SaaS provider will provision a separate Production Instance for their Life Sciences consumers and will only allow a new release after testing in a suitably controlled Test Instance.

Some SaaS providers specializing in Life Sciences are starting to take this approach and although the provisioning of separate Instances and additional testing does increase the service provision costs this is more than offset by the reduced testing that needs to be conducted by the Regulated Company.

Platform as Service Issues

As stated above, from a Life Sciences industry perspective there is relatively little difference between IaaS and PaaS service models – the difference is really the provision of an operating system, programming languages and the tools provisioned in the PaaS model.

Where a PaaS model is being leveraged the Regulated Company is responsible for ensuring that their enterprise application is compatible with the platform being provisioned. In most cases the service provider will provide guidance and will confirm that the application can be supported, but as always it is the Regulated Company who remains accountable.

Where there are compatibility problems e.g. the provider always deploys the latest version of Java, but the enterprise application requires an earlier version (or vice versa) the Regulated Company still has the option to use an IaaS model upon which they can deploy their own operating systems, programming languages and tools.

Hosting and Managed Services versus ‘The Cloud’

As defined by NIST, Cloud Computing has essential characteristics which are defined as:

  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured Service

While many hosting and managed services companies meet a number of these characteristics (i.e. broad network access via the Internet, resource pooling via scalable architectures and provision of a measured service via a suitable Service Level Agreement) many do not provide an on-demand service (“A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider”) and rapid elasticity (“Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in.”).

It is the ability to quickly scale the use of the enterprise application (e.g. to add additional processing resources at a month end financials close, or quickly add hundreds of new sales users to a CRM system with no degradation in performance) that differentiates traditional hosting and managed services from true Cloud Computing.

The ability to provide on-demand self-service brings potential risks to the validated state of a hosted enterprise system. While the service provider may provide on-demand self-service the Regulated Company nevertheless retains accountability for effective change control of the application and any requests made of the service provided should go through an internal change control and authorization process.

Rapid elasticity may also pose problems if changes to the underlying Infrastructure are made with insufficient control. While the technology allows additional memory, processors, disk space to be rapidly allocated and de-allocated it is important that this is controlled and that the service provider has suitable change control, configuration management and infrastructure qualification process in place to maintain control.

Date of Publication: July 2012
ISBN Number: 1933722614
Number of Pages: 467
Binding: Hardcover