Contact Info
701 E Santa Clara Street Suite 42
Ventura, CA 93003
info@roqmetrics.com
877-221-0767
Follow Us

CS Assure

Who is accountable for the GxP cloud solution?

Who is accountable for the GxP cloud solution?

The first time that we encountered this question, it caught the team off guard. Why would the accountability be any different, we thought. Isn’t the life science company ultimately accountable for all of their systems regardless of where it is hosted? The team was faced with the challenge of explaining that ultimate accountability doesn’t change. 

Eventually, we decided that the best response to this question is to shift the conversation to a discussion of risks to drive a more productive and proactive conversation. And it was important to make a clear distinction between accountability and responsibility.  The main difference between responsibility and accountability is that responsibility can be shared while accountability cannot. Being accountable not only means being responsible for something but also ultimately being answerable for your actions. So first we must ask ourselves, who is answerable to the FDA? This makes the life science organization accountable while responsibility is shared with the cloud provider.

Start by following your standard risk management approach. Identify and categorize risks and evaluate them based on risk to the patient, product quality, and business process. Risks can manifest themselves in different areas. Below are some of the common areas to focus on when working with cloud vendors:

  • Change Management
  • Application Validation
  • Hardware, OS, and Security
  • On-going Support
  • Infrastructure Qualification

Once the risks are known, you’ll want to identify where the risk is most likely to occur (vendor/customer) and develop a mitigation plan. The location of the risk depends on the cloud solution landscape. Next, you will want to carve out vender responsibilities. Remember, accountability still lies with the life science organization.

IaaS Vendor Risk

Requirements and Design

Same or similar to efforts for On-Premise Deployments.

Validation Master Plan

Same or similar to efforts for On-Premise Deployments.

IQ/OQ/PQ

IaaS vendor is responsible for evidence of Physical Security to be included in the platform qualification.  The customer is responsible for all aspects of validation from Installation Qualification through to Performance Qualification.  Note, application vendors may provide validation packs or documentation, which may be used to alleviate some of the internal efforts.

Change Management

The customer and vendor share responsibility for managing change to infrastructure.  The customer is responsible for all changes to configuration/customization.  Depending on your deployment type, the vendor may provide validation assistance with regards to the OQ.

Infrastructure as a Service enables organizations to leverage economies of scale and specialization to setup cloud infrastructure, which is vendor managed versus building out an environment on-premise. IaaS allows companies to put some of their workloads in the cloud, enabling companies to focus their time on more mission-critical items.

With Infrastructure as a Service, most of the vendor risk is associated with the hardware, operating systems, and security and must be identified and mitigated. The most straight forward way to identify and minimize IaaS vendor risk is to request evidence of industry certifications and qualification plans. All aspects of the infrastructure must be qualified to show that the infrastructure works as intended and is subject to change control.

The qualification plan should specify the following:

  • IQ Plan and Protocol
  • Checklists for Hardware and Software
  • Installation Specifications
  • Change Management System and Procedures
  • IQ Summary Report

We also recommend periodic vendor audits to ensure that the vendor’s infrastructure remains in a qualified state. Vendor audits should include an assessment of infrastructure security, access management, data management, and service level agreements. Look for evidence of risk analysis of hardware failure, network errors, and access and geographic location of data.

PaaS Vendor Risk

Requirements and Design

The vendor should be able to provide a Functional Specification document with regards to the core platform functionality.  This will impact your technical design document.

Validation Master Plan

The overall set of tasks are not changed, however, there is a greater shift from the customer to the vendor to qualify the hosted environment as well as validate the underlying platform.

IQ/OQ/PQ

Platform vendor is responsible for evidence of Physical Security to be included in the platform qualification.  Application vendor should be able to provide IQ and OQ documentation, PQ remains the responsibility of the customer.

Change Management

The Vendor is providing both infrastructure and development/configuration environments, which should be part of an upgradeable package.  The vendor should provide validation documentation with regards to the changes in the core platform for each release, otherwise, this becomes the responsibility of the customer to assess the changes and validate both OQ and PQ.

Platform as a Service provides organizations with a full suite of services, including the infrastructure to host software and applications, as well as the configuration and development tools to build enterprise software applications. An example of this would be the salesforce platform.  

With Platform as a Service, some additional risk begins to shift to the vendor, including the change management and on-going development and support of the vendor-provided platform. Any application that you build is dependent on the underlying platform. It is crucial to assess the risks related to the vendor’s platform, including their development process, validation process, infrastructure qualification process, deployment process, and source code management.

SaaS Vendor Risk

Requirements and Design

The vendor should be able to provide a Functional Specification document with regards to the core platform and application functionality.  This will impact your technical design document.

Validation Master Plan

The overall set of tasks are not changed, however, there is a greater shift from the customer to the vendor to qualify the hosted environment as well as validate the platform and application.

IQ/OQ/PQ

The vendor should be able to provide IQ and OQ documentation, PQ remains the responsibility of the customer.  Note, as vendors are delivering software configurations, this may reduce the amount of effort required to validate the PQ, depending on how much or little is used.  This will vary by vendor and their approach.

Change Management

The vendor is providing both infrastructure and development/configuration environments and pre-configured solutions, which should be part of an upgradeable package.  The vendor should provide validation documentation with regards to the changes in the core platform for each release, otherwise, this becomes the responsibility of the customer to assess the changes and validate both OQ and PQ.  Note, in regards to the IQ, this will depend on the vendor and their approach to hosting.

Software as a Service offers a complete suite of solutions for those looking to migrate into the cloud. In addition to all of the services provided by IaaS and PaaS, vendors will provide industry configured solutions designed to speed up the time to value for deployments.

With Software as a Service, you will want first to confirm the infrastructure qualification as described above, and then devote your time to identifying risks related to the software solution validation. Since this is a GxP solution, you’ll want to confirm that the software contains the following validated features that comply with 21 CFR Part 11 and Annex 11: Audit Trail, Authorization Controls, Data Integrity Checks, and Electronic Signatures. All aspects of the solution must be validated by the vendor to show that they work as intended and are subject to change control.

The validation plan should specify the following:

  • IQ Plan and Protocol
  • Checklists for Hardware and Software
  • Hardware and Software Installation Specifications
  • OQ Plan and Protocol
  • Validation Summary Report

We also recommend periodic vendor audits to ensure that the vendor remains compliant with your expectations. Vendor audits should include an assessment of application security, access management, data management, service level agreements. Look for evidence of risk analysis of feature failure, data integrity and access, and geographic location of data.

And as with PaaS, you will want to access the vendor’s development process, validation process, infrastructure qualification process, deployment process, and source code management.

PSaaS Vendor Risk

Okay, we made this acronym up but you get the idea. PSaaS is a combination of PaaS and SaaS. An example is an industry/process-specific software as a service (SaaS) application developed and distributed on top of a Platform as a Service (PaaS). An example would be a quality management application built on top of the Salesforce platform. Another example is validateMyApp.com, a computer system validation management application built of the Salesforce platform. PSaaS apps give SaaS applications added platform benefits, such as an application development environment, reporting engine, analytics, and more.

With PSaaS, a combine risk approach should be taken to cover IaaS, PaaS, and SaaS as described above.

Conclusion

Remember, you, the life science organization are accountable for the system. Assess and periodically audit your cloud provider where responsibility is shared or solely owned by the vendor. Accountability cannot be shared but risks related to responsibilities can be mitigated!

ValidateMyApp!

ROQMetrics, Inc,

701 E Santa Clara Street Suite 42, Ventura CA 93003

(877) – 221-0767

Post a Comment