Considerations in SaaS Validation

SaaS Qualification

Hello good people of the world! Today’s post is about qualifying Software as a Service (SaaS), also known as “cloud-based” or “hosted” software. Simply, SaaS is any computer system in which any server is not hosted by the system owner. Here are some key considerations in qualifying SaaS computer systems:

  1. The Vendor Audit: The vendor audit is critical because when you’re not hosting servers onsite, you’re giving up a lot of control, but because you’re in a regulated industry, you’re not relieved of any of the compliance responsibility. The vendor audit needs to include a comprehensive assessment of the vendor’s quality program. You need to make sure documented procedures are in place for things like:
    • Data backup and restoration
    • Physical and electronic security measures
    • Training
    • Change management
    • Issue/deviation/variance resolution

    Ask for and verify specific instances of each element of the quality program to ensure procedures are being followed. Based on the audit, a contract must be documented and approved covering roles and responsibilities on each side, typically called a Service Level Agreement (SLA).

  2. Define the Scope: The vendor audit is just part of the qualification or validation plan for your SaaS system. Other aspects to consider:
    • What are the hardware and software components? Identify each server, router, switch, etc. uniquely and identify the GMP-impact via a formal document method.
    • What documentation is there and what documentation must be created? What level or testing has the vendor already performed and what availability, if any, is there of that documentation to you?
    • What are the risks associated with the project?
  3. Document the Plan: I’m a firm believer than any computer system validation (CSV) project needs to have a formal documented plan, whether hosted or onsite. The Validation Project Plan (VPP), as it is typically called documents the roles and responsibilities, project definitions, validation approach, deliverables, etc. for the entire system lifecycle and is approved by all stakeholders. A formal VPP gets everyone on the same page and expedites a project to its successful conclusion.
  4. Execute the Plan: Like any project, there will be changes once you get started. Be flexible, but don’t take shortcuts. Update your documentation and keep everyone informed as you go, and at the end you’re sure to have a well-vetted validated SaaS system.

What issues have you run into in the validation of “hosted,” “cloud-based,” or SaaS software systems?

Like this MWV (Mike Williamson Validation) post? Be sure to like, share, and subscribe!

2 thoughts on “Considerations in SaaS Validation”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.