Implementing a new eQMS raises questions that go far beyond software features. SaaS eQMS validation, documentation, ownership, and regulatory expectations all come into play.
That’s exactly why we created the eQMS series: to cover what organizations need to understand before they start working in an eQMS.
In the fourth eQMS series, The eQMS validation process explained: steps, risks, and best practices, we explored what regulators expect, how validation responsibilities are shared in a SaaS model, and how to validate an eQMS in a SaaS model in a way that is both compliant and practical.
The discussion combined deep validation expertise from Yves Dène, Senior CSV Specialist, with real-world onboarding insights from Catherine Kolar, Scilife’s Onboarding Project Manager. Together, they covered validation from both the compliance and implementation perspectives, connecting regulatory theory with day-to-day execution, and eQMS validation best practices.
SaaS eQMS validation: what is a SaaS solution, and why does it change validation
Before we dig into SaaS eQMS validation, let’s start with the basics. What is Saas?
Software as a service (SaaS) allows users to access cloud-based applications over the internet without installing or maintaining software locally. Common examples include email, calendars, and productivity tools such as Microsoft 365. In regulated environments, SaaS is increasingly used to support electronic quality management systems (eQMS).
Unlike traditional on-premise systems, SaaS platforms are updated frequently and may support multiple customers (multi-tenant models). They also have separate infrastructure ownership from system use.
However, these characteristics do not remove eQMS validation requirements. Instead, they shift how validation is performed.
In a SaaS model, validation responsibility is shared:
- The vendor is responsible for the infrastructure, platform development, and core functionality.
- The customer remains responsible for validating the system for its intended use, including configuration, workflows, processes, and ongoing changes.
So, how to stay validated with SaaS releases and change control? SaaS validation must be treated as a lifecycle activity, supported by change control and impact assessment to ensure the system remains validated over time.
What is computer system validation (CSV)?
Computer Systems Validation (CSV), at its most basic level, is the process of ensuring that applications, systems, solutions, and/or environments satisfy intended functionality consistently and reliably.
Title 21 CFR Part 11 eQMS validation requires the “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” The main benefit of validation is a high level of assurance that the system will perform as required and as intended during operation.
Validation is evidence-based, not trust-based. Regulatory expectations require objective evidence that a system performs as intended for a specific use case. Validation must be demonstrated through documented eQMS validation requirements, risk assessment, configuration records, testing, and ongoing change control.
About SaaS eQMS validation: When does a SaaS eQMS need to be validated?
One of the most common questions on how to validate an eQMS in a SaaS model is how a customer can determine whether their newly acquired eQMS solution must be validated.
The first thing to consider about SaaS eQMS validation is which applicable regulations and standards apply to a company. This is important to revisit regularly, especially for startups or rapidly growing organizations because regulations can change and new eQMS validation requirements can become relevant over time.
Examples include requirements associated with laboratory, clinical, manufacturing, and distribution practices, medical device requirements, and privacy considerations.
Once the regulatory context is understood, a good practice is to create and perform a criticality assessment. A criticality assessment functions like a basic questionnaire to list the standards and requirements that could impact the selection and implementation of the system.
It helps clarify which regulations are in scope for the system and how the system needs to reflect those requirements. The end result of that assessment helps determine whether validation is required and, if it is, what level of effort is appropriate.
Regulatory expectations for SaaS eQMS validation
Auditors and inspectors do not expect a single rigid validation methodology. Instead, they look for a structured, risk-based validation approach that demonstrates control over the system throughout its lifecycle.
Key expectations include:
- Risk-based validation, lifecycle approach: validation activities should be scaled according to risk. Higher-risk functionality requires more controls and testing, while lower-risk areas require less. Validation must continue after go-live.
- Clear ownership of responsibilities: In a SaaS model, responsibilities are shared. Vendors manage infrastructure and core platform elements; customers validate intended use, configuration, and processes.
- Supplier oversight and vendor qualification: organizations must assess and qualify SaaS vendors, ensuring they are capable of supporting regulated use through appropriate documentation, transparency, and contractual controls.
- Objective evidence of control, including:
- Documented intended use
- Defined user requirements
- A risk assessment appropriate to the system and its use
- Testing evidence showing the system performs as required
- Change control records for vendor releases and internal changes
- Ongoing validation, not “validated once”: because SaaS platforms evolve, validation cannot be a one-time exercise. All vendor releases and internal configuration changes must be assessed for impact. Also, avoid retrospective validation at all costs.
“I don’t like the word ‘retrospective’. It immediately signals you could have done the job better.”
Yves Dène, Senior CSV Specialist
How to validate and implement an eQMS SaaS: eQMS validation best practices
Now, let’s talk eQMS validation best practices. A practical SaaS eQMS validation approach typically includes:
Vendor and platform assessment
- Evaluate the vendor’s development, testing, and compliance practices
- Perform a risk assessment based on your intended use
- Leverage vendor IQ/OQ documentation where appropriate
Planning and documentation
- Master Validation Plan (scope, responsibilities, strategy)
- User Requirements Specification (URS)
- Risk-based validation approach rationale
Execution and testing
- Performance Qualification (PQ) / User Acceptance Testing (UAT)
- Verification of workflows, roles, and configurations
- Data integrity checks
Analysis and reporting
- Document test results and deviations
- Produce a validation summary confirming fitness for use
How to stay validated with SaaS releases change control
- Manage releases, incidents, backups, and ongoing monitoring
“Ongoing validation requires a validation methodology, structured change control, and robust IT infrastructure procedures.”
Yves Dène, Senior CSV Specialist
Computer System Validation plan template - forget about spending long hours on verification and data mapping.
Validation for startups or paper-based teams implementing SaaS
For organizations implementing an eQMS for the first time, validation should start with process clarity.
Not all quality processes must be automated at once. Teams should first decide which processes belong in the eQMS and define user requirements based on those processes. These requirements form the foundation of validation.
Cross-functional involvement is essential. Stakeholders may include quality, operations, production, and other departments, depending on system use. Mapping current and future workflows early helps prevent late changes and validation rework.
Off-the-shelf SaaS solutions are generally preferred over custom-built systems, as customization significantly increases validation effort and risk.
“Never forget: many teams are startups, regulations change, and new requirements can become relevant over time. You have to stay up to date.”
Yves Dène, Senior CSV Specialist
How to validate an eQMS in a SaaS model with existing validation methodology
For organizations with established internal validation practices, the key is ensuring that their validation methodology, policies, procedures, templates, and overall approach explicitly support SaaS models.
As seen above, a critical difference in SaaS is that the infrastructure and part of the software lifecycle are managed by the vendor. However, the customer still must ensure these meet regulatory expectations, and everything must be documented.
Supplier qualification becomes especially important. Vendors should demonstrate compliance maturity and provide documentation that customers can leverage, not recreate.
Shared responsibility in SaaS eQMS validation
No vendor can deliver a “100% validated system”. As stated above, SaaS eQMS validation requires objective evidence that software specifications conform to user needs and intended use.
These are never the same across companies. Even with the same platform, organizations may have different document types, CAPA categories, and configurations. Because of that, customers must be able to demonstrate that the system is validated for their specific use.
“We tell our customers and prospects that with the proper leveraging of our validation package, Scilife is 95% validated, leaving just 5% of the burden on them.”
Catherine Kolar, Onboarding Project Manager
We’re talking about a “pre-validated platform”, where vendors can provide a large portion of validation evidence and tools, but customers must still complete validation activities that demonstrate the configured system supports their intended use.
- What no SaaS vendor can do:
- Prove fit for your intended use
- Validate your workflows
- Assume your regulatory accountability
- What vendors can provide:
- Pre-validated platform evidence
- Standardized workflows
- Documentation and templates
SaaS eQMS validation of the Scilife platform: GAMP 5 and Computer System Validation
Scilife uses a GAMP 5 and Computer System Validation approach for validating the system on the Amazon Web Services (AWS) platform.
As part of the validation phase, the Scilife platform is validated for, e.g., standard functionality and workflows in an environment independent of customers. This validated environment for standard functionalities and workflows can be used as-is by our customers if their business process is aligned with the Scilife platform default workflow.
Our validation package includes a drafted, executed, and signed-off validation documentation set that customers can use as the basis for the validation of Scilife on their end. All showcased options are risk-based approaches. This document effectively eliminates most of the costs and resources needed for validation by our customers.
Scilife’s customer validation package
Our validation package for customers includes signed, approved, and documented evidence of the following elements:
- Validation Plan
- User Requirements Specification
- Risk Analysis
- Configuration Specification (CS)
- Traceability Matrix
- Test Plan
- Installation and Operational Qualification documents
- Performance Qualification document
- Test Summary Report
- Validation Summary Repor
1. Validation Plan
This plan outlines the validation approach, activities, responsibilities, and deliverables for validating the Scilife platform.
2. User Required Specifications (URS)
The URS identifies end-user requirements for the system. This document defines what the system should do to satisfy business needs and how the system should function to comply with all applicable regulations.
3. Risk Analysis
This document is directly related to the User Requirements Specification (URS) document. It is important to identify and mitigate risks that come with the various URS items.
Each URS item is analyzed to identify potential risks that specific functionality may pose from a GxP or a business requirement perspective. Once identified, these risks are classified according to their severity and probability, after which mitigation of the risks is described to assign a risk priority.
4. Configuration Specifications (CS)
The CS contains configuration requirements in terms of preconfigured settings in the system. The objective here is to explain the configuration options of the Scilife platform and to document the details of user roles and their permissions/accessibility.
8. Traceability Matrix
This tool ultimately ensures that all specified requirements are met. The matrix establishes the relationship between requirements and testing activities that demonstrate the requirement is satisfied. It also provides a cross-reference between requirements and procedures or external controls to satisfy a specific requirement.
5. Test Plan
The Test Plan lists the procedures needed to verify the proper installation, configuration, and operation of this platform in the validation and production environments.
6. Installation and Operational Qualification (IOQ)
IOQ provides assurance that the application and its supporting infrastructure have been correctly installed and configured, and that the complete integrated system functions as specified before executing the Performance Qualification.
7. Performance Qualification
This test evaluates the application by users in conjunction with their knowledge of the business processes required to perform certain tasks. It involves the execution and documentation of specific tests designed to demonstrate that the application performs as expected and meets the users’ specified requirements.
9. Test Summary report
This report summarizes the activities that verify the testing process/test results for the Installation Qualification, Operational, and Performance Qualification testing.
10. Validation Summary report
This document summarizes the results of all activities and the status of the deliverables identified in the Validation Plan. It helps to determine if the Scilife platform was properly implemented according to the predefined specifications and operates as intended.
Initial implementation approach for customers
- Initiate a change request to explain the change from a manual to an electronic process using the Scilife SaaS platform, along with the reason, impact, and risk assessment.
- Document the configuration changes you plan to do in your system, along with how you will verify those configuration changes. Attach verification screens with the change request.
- Develop any SOPs/WIs where applicable as per your business for all different modules, or simply refer to the Scilife Knowledge Base.
- Go live in the production environment.
- Close the change request.
After going live, all changes to the customer environment will be driven by the change management process to ensure that all changes to the customer environment are documented.
Scilife was developed following regulatory requirements, being fully validated by us according to GAMP5/21CFR11/Annex11.
Managing SaaS releases and staying validated
How to handle various releases from Scilife:
- Minor releases/Hot fixes: Since minor releases do not involve any change in features and processes, no additional effort is required from customers. Customers can review the change request and the release notes provided by Scilife to understand the minimum changes released. If customers identify any change that impacts configurations they have already carried out, then they can follow the process as documented below for Major and Medium releases.
- Major/Medium releases: Initiate change requests to document the impact of changes released on current configurations. If the new release has an impact, document the configuration changes you plan to do in your system, along with how you will verify those configuration changes. Attach verification screens with the change request.
- Update any SOP/WI if the new release has an impact on these documents.
- Close change request.
The Scilife SaaS platform is maintained in a validated state by ensuring these listed procedures are followed:
- Operational and maintenance SOPs/policies/WIs
- Change management information
- Incident management
- Disaster recovery
- Data backup and recovery
- Personnel (including qualifications and training)
Common mistakes in SaaS eQMS validation
Planning and execution gaps are a common source of problems in implementation projects.
When key activities are overlooked early or addressed too late, teams often face increased risk, rework, and compressed timelines near go-live. Some key issues are:
- Validation deliverables and timelines are often not considered upfront, leading to schedule compression later in the project.
- Failure to clearly define current processes and future workflows early allows new requirements and changes to emerge late, increasing risk close to go-live.
- Teams may adopt vendor-supplied user requirements without verifying they align with their actual business and compliance needs.
- Small configuration settings can significantly affect workflow behavior, such as reviewer sequencing or approval rules.
- Inadequate risk identification undermines the risk-based validation approach expected in regulated environments.
- Insufficient testing can allow process gaps or misconfigurations to remain undetected until after go-live.
- Inconsistent metadata or document structure can cause major issues during migration.
- Delayed SOP updates, especially when moving from paper to electronic workflows, can result in going live without the required compliant operating framework.
Conclusion: validating SaaS the right way
Validation should reduce risk, not add friction. When responsibilities are clear and evidence is leveraged correctly, SaaS can significantly lower validation effort compared to traditional systems.
Scilife’s role is to reduce the burden, provide validated evidence, and support compliant implementation, while customers retain control over intended use and regulatory accountability.
