Chat with us, powered by LiveChat

A Guide to Validated Software as a Service (SaaS)

Validated Software as Service

Quality Assurance Specialist with Compliant Cloud Nicola Brady dives into the nitty gritty of Validated SaaS,
including what it involves, the elements of vendor evaluation, and the responsibilities associated with validation.

Software as a Service (SaaS) is a software deployment model where a vendor hosts a software application and makes it available over the Internet.  SaaS has become an essential distributed software deployment model for providers, and its acceptance has grown exponentially across organisations of all sizes and types.  Interestingly, new vendors, in any application market, tend to have SaaS as their only delivery model and that very fact presents a significant challenge to regulated Life Science companies in particular, who are traditionally very conservative in adopting new approaches and tend to retain many on-premise applications.

That said, Life Science companies are moving gradually and cautiously towards SaaS applications in an effort to reduce the costs associated with on-site software development and deployment models.  In addition to this, considering many new software applications are SaaS-only models, the Life Science sector will need to quickly develop the regulatory knowledge and IT / Compliance skills to
successfully utilise these new SaaS offerings in a “validated” and “compliant” way.While the regulated company is ultimately responsible for the validation of the SaaS to confirm fitness for intended use and the maintenance of its overall compliance, choosing the right SaaS vendor can go a long way towards lessening the validation burden.

The SaaS software deployment model makes the software available to all subscribers i.e. those that have agreed to
consume the service from the vendor. The application software is owned, delivered and managed by one or more providers.  A SaaS subscriber is exposed only to the application and its configuration and does not monitor, manage or control the underlying infrastructure (including network, servers, operating systems, storage, databases or application platform services) or software updates. This is a very critical point when we consider that Life Science companies must ensure that; ’The application should bevalidatedIT infrastructure should be qualified. ‘(EU GMP Annex 11)

The SaaS validation effort

For a standard software validation exercise the client has sole responsibility for the Software Development Lifecycle
(SDLC) and all the activities therein. For the validation of a SaaS application, a significant reduction in effort can be achieved through moving some of the validation activities to the vendor and leveraging vendor documentation. GAMP 5 states ‘maximize supplier involvement through the system lifecycle in order to leverage knowledge, experience and documentation subject to a satisfactory supplier assessment’ and ‘avoid wasted effort and duplication’ (GAMP 5)

The relative reduction in the validation
activities required, by the client/subscriber, to deliver a SaaS is heavily dependent on the quality of processes, documentation and controls in place at
the SaaS vendor.  Remember that it is a regulatory requirement that the software is validated, and the infrastructure is
qualified. Choosing to consume a SaaS software offering does not remove this regulation.  Selecting the right SaaS
vendor is key and any potential SaaS provider should be evaluated to confirm that their systems, processes and validation methodology are in alignment with the regulated company’s (client / subscriber) expectations.  

The regulations stipulate that a vendor audit or assessment be performed regardless of the degree or scope of
activities that the SaaS vendor will perform. 
This vendor evaluation is even more critical when a client / subscriber is looking to leverage the vendor activities to meet their validation
requirements.  The vendor evaluation should consider the following elements:

  • Software Development Lifecycle (SDLC) methodology
    & documentation
  • Project Management Processes
    • Personnel Qualifications (QA, Technical)
    • Documentation Standards & Procedures
    • Methods for Review & Approval
    • Design Standards
    • Configuration Management
    • Testing Standards
    • Clear separation of Development, Test and Production
      Environments
    • Change management processes
    • Corrective and preventive action processes
    • Training processes
    • Release documentation
    • Service Delivery Processes (Maintenance, Support)
    • Physical and logical security controls for system /
      data
    • 21 CFR part 11 compliance as applicable

Based on the data from the vendor audit or documentation evaluation, the regulated client/subscriber can then perform a risk assessment to document and determine the extent to which the vendor documentation can be leveraged to support the overall validation exercise for the SaaS.  The qualification of the host infrastructure must also be considered.  Table 1 below highlights the responsibilities associated with the validation exercise: 

Table 1: Typical Responsibilities for Validation of SaaS

A guide to validated software as a service

The contract with the SaaS provider

Under European Regulations, EudraLex Chapter
7, there are also very specific regulations concerning outsourced activities-which SaaS is considered- and adherence to these regulations must be provided
in evidence in the event of a regulatory inspector requesting this information.It is never sufficient in these circumstances to state that “the vendor looks
after that”.

Documenting the agreement or contract with the SaaS vendor is as, if not more, important than the validation exercise.  The contract should contain the following details at a minimum:

  • Ability of SaaS vendor to carry out the
    outsourced activity satisfactorily
  • Restriction on sub-contracting to third
    • parties
    • Restriction on unauthorised changes
    • Availability of the SaaS vendor for
      regulatory inspection

Remember, the SaaS vendor is not a regulated entity so the ultimate responsibility and accountability for the SaaS
lies with the regulated client / subscriber. While the responsibilities, communication processes and technical aspects of the contract are key, the
regulated client / subscriber’s quality system must be set up for control and review of the outsourced activities associated with the SaaS.  Only then can the potential risks associated with outsourcing software deployment to a SaaS vendor be mitigated.

 

Share this post

Share on twitter
Share on linkedin