Software as a Service (SaaS) products are being utilized by Life Science companies to address solutions for some specific regulated practices and processes. One such product, from my previous experience, is a Learning Management System. The software provides the ability to assign training requirements to employees, provide notifications to personnel of training assignments, track the training module completion against assigned deadlines, and provide program analysis and reporting on the Training Program performance.
Training of personnel is a basic regulatory requirement which makes training records GMP data. As such, this type of system will need to be developed, implemented, and maintained as a validated program/system. The following article will highlight several items that should be considered when auditing SaaS providers.
Auditing SaaS Providers
The SaaS product provider retains ownership and maintenance of the software and hardware components of the system, and leases the use of the program to the client. Client companies will own their database of information; however, the management and utilization of the data is conducted through a cloud environment connected to the provider’s program and facilities. This brings up a unique situation with regard to ongoing GMP auditing of the program and system. From a regulatory perspective, the overall responsibility for demonstrating the validated state of the program/system remains with the client. However, much of the development and ongoing upgrades/enhancements/changes to the system will be managed by the provider.
A periodic auditing program of the provider’s software development, validation, and maintenance processes is certainly in order. I don’t intend to address an in-depth review of auditing requirements, however, the following items should be considered for evaluation during a GMP audit.
Does the validation methodology utilized provide a defendable process for the delivery of a GMP system?
- Has the program been developed against documented User Requirements?
- Are the testing protocols, etc., completed using good documentation practices (GDP)?
- Is there a documentation index readily available to align with the development, implementation, and maintenance processes?
Is there a suitable change control process in place for development and ongoing maintenance of the software program?
- At some point, generally following approval of the final User Requirements, a formal, robust, change control procedure must be implemented. This change control procedure must include evaluation of the proposed change(s) by individuals qualified to determine the impact of changes to the User functionality and the required deliverables to allow implementation of the proposed changes.
- This same change control procedure will need to remain in effect as the provider proceeds through program enhancements, problem resolution, and program upgrades.
Is there documented evidence demonstrating that the program has been tested and operates as specified?
- This is the primary question that will need to be addressed during a regulatory inspection of the GMP system.
- The most convenient way to document this is through the utilization of a Traceability Matrix; when generated appropriately, this document will be able to trace all testing back to User Requirement revisions as changes are implemented for the software program.
The SaaS provider may or may not own the facility where the system hardware components are located. Regardless of whether the provider uses their own facility, or outsources the storage of system hardware, these facilities will also need to be audited. The following items should be considered:
Is access to the facility secure?
- Access to the system hardware must follow a secured pathway.
- Access must be limited to appropriate personnel, and documentation must be available to identify all individuals accessing the system, i.e. date and time stamp.
Are storage and housekeeping conditions appropriate for computer equipment?
- Two important components here are the internal temperature of the facility, and evidence of dust issues.
- Both of these items can have a detrimental effect on computer hardware functionality; facility airflow should be adequate to address concerns with both of these items.
Are facility utilities, i.e. fire suppression, UPS, etc., appropriate for computer equipment?
- Fire suppression systems should be implemented with the objective of minimal impact to the hardware components located in the facility (this can be a significant problem).
- An uninterruptible power supply (UPS) should be evident and should be periodically tested for effectiveness.
SaaS Program Maintenance
As noted previously, maintenance of the validated state of a SaaS program is the responsibility of the client company. As such, User Acceptance Testing should be conducted by the client and documented accordingly.
A formal change control procedure must be in effect to allow evaluation of each system enhancement, upgrade, or change, against the existing User Requirements specification(s). Generally, SaaS providers will provide notes with system changes to allow the client to evaluate the impact of the proposed change to their current system functionality. The client will usually have the ability to decide if the change is accepted or delayed until further upgrades become available. If changes are accepted, the user acceptance testing will need to be conducted by the client, including any regression testing needed to demonstrate that existing functionality is not impacted by the change being implemented.
All of these items should be included in a formal Quality Agreement between the client and the SaaS provider.
This is certainly not intended to be a comprehensive listing of all items that need to be evaluated during GMP audits of SaaS programs/systems. My objective was to highlight several areas and items that came to light during my experience with a Learning Management System.
Are you considering the use of a SaaS program/system? Do you have questions regarding the GMP auditing of such systems and providers?
Please give me a call and let’s discuss the potential support that The Catalyst Compliance Group can provide to your project.
Richard D. Schlabach is a Quality Assurance professional with over 37 years of pharmaceutical industry experience in Quality Assurance, Quality Control, and Validation functions for a wide variety of product categories. Richard’s technical competencies include extensive knowledge of worldwide regulatory requirements; equipment, utility, process, and cleaning validation; specialization in automation validation; compliance auditing and training; and preparation of SOPs and related documentation. He holds Merck certifications as an Automation Auditor, Non-Sterile Product Auditor, Sterile Product Auditor, and API Auditor. He is currently the VP of The Catalyst Group’s QA Division.
Mr. Schlabach can be reached at the following contact information: