Software Validation / Verification from the Supplier's Perspective.
In precise terms, software is verified - what gets validated is the computerized system in the operator's process. The market calls both software validation, and we use the term deliberately. What counts is the division of roles behind it: the regulated company also answers for what you deliver, and therefore has to assess you. Suppliers who are prepared turn that assessment into a market advantage - quality that shows in an audit decides supplier selection.
Why your customer must assess you.
The terms first, because the roles hinge on them: software is verified against its specification - validated is only the computerized system at the operator's site, against its intended use. The market calls both "software validation"; we follow that usage deliberately and mean it precisely: your verification, plus the evidence your customer's validation builds on. Both follow the same life cycle model - the one behind GAMP 5 validation.
Your lifecycle is your evidence.
Regulated customers expect good practices from software suppliers across the entire lifecycle - from your own QMS to planned retirement. And the benchmark is clear: you are measured not against your customer's QMS, but against demonstrable adherence to your own. The product itself is measured too: audit trail, unique user binding and signature capabilities are judged against the requirements for electronic records and signatures.
- 1
QMS & quality planning
Documented procedures, competent personnel, evidence of adherence, continuous improvement - plus a quality plan per product showing how the QMS takes effect in practice, and a formal assessment of your own sub-suppliers.
- 2
Requirements & specification
Clear requirements - provided by the customer or defined together - and a specification that aligns the product with them.
- 3
Design review & development
A formal design review against requirements, standards and identified risks; development and configuration to defined standards, including code review.
- 4
Testing & verification
Testing against approved test plans and specifications, with demonstrable coverage of the requirements - the verification that underpins the market term software validation.
- 5
Commercial release
Release to customers follows your formal process. Release into the GxP environment is expressly not part of it - that remains the regulated company's task.
- 6
Operation, changes & retirement
Support and maintenance as contracted, a fully described change process - so customers can maintain their validated state - and, at the end, a planned, documented retirement.
Where does your product stand - and what does your customer need from you?
Supplier involvement scales with the product type. The GAMP categories distinguish the product types; for services, what matters is which level you operate: the business application that carries business processes and GxP data - or the platform layers beneath it.
| Product type | Typical involvement on the customer side | What your customer needs from you |
|---|---|---|
| Standard product (GAMP Category 3) | Documentation, training, support and maintenance | Evidence of good development and maintenance practice - largely delivered before the customer relationship even begins |
| Configured product (Category 4) | plus support with specification, configuration, verification and operation | agreed procedures, documented in the plan - from your QMS or the customer's |
| Custom development (Category 5) | involved across the entire project lifecycle, then in operational support | complete lifecycle evidence following agreed procedures |
| Business application as a service (SaaS) | You operate the application and the layers beneath it - yourself or through your own suppliers | product evidence and operational records together, including your sub-supplier chain |
| Platform as a service (IaaS/PaaS) | You deliver the platform layers your customers' applications run on | qualified layers and lived IT processes under your own QMS |
For platform providers the evidence is twofold: qualified layers, and the IT processes that run them - without lived change and security management, even a qualified environment loses that state. Cloud services (per NIST SP 800-145: on-demand network access to a shared pool of resources) are the same layered world, delivered as a service.
Contracted, not claimed.
For you as a supplier, the regulations themselves are not what binds you - binding is what your contract with the customer makes of them. The more layers you operate, the wider the gap between what your customer answers for and what they actually control. That gap is closed by a clean split across three instruments, each sized to risk:
- Contract: the responsibility split, duties to cooperate - and your customer's right to audit
- Service level agreements: operating commitments that match the risk of the processes they carry
- Quality agreement: the quality obligations of both sides - explicitly expected for cloud services
We audit for one side - and prepare the other.
We have conducted more than one hundred audits - among them, currently, the audit of a cloud provider for a manufacturing execution system. We bring the same experience to your side of the table: in the mock audit that anticipates your next customer audit, in training your development and QA teams, and in building the evidence auditors actually ask for.
The reference documents, from binding regulation to guidance:
Frequently asked questions from the supplier's perspective.
No - only the operator can validate: validation demonstrates that the system fulfills its intended use in the specific business process, and both sit with the regulated company. The supplier verifies its product and documents the lifecycle; the more robust that evidence, the less the customer has to generate for its own validation.
As a building block, yes; as a substitute, no. The certificate attests to a management system, the SOC 2 report attests to controls - neither covers the GxP expectations, from the documented lifecycle to the change process. That is why regulated companies assess for themselves, risk-based.
Your QMS and how it is lived: procedures, staff competence, evidence from day-to-day work - and, on the product side, the lifecycle from requirements to change management; for services, operations and sub-suppliers as well. Your strongest argument is a QMS that holds to what it itself lays down.
As deeply as the risk of the processes it carries demands. The focus is on the qualified layers, the IT processes that keep them in a controlled state, and your own supply chain. What matters most is the criticality of the applications running on the platform.
From product to validated system.
Pass your next customer audit - before it takes place.
In a free intro call (about 30 minutes), you outline your product type and maturity - we name the evidence gaps an auditor will see first, and the concrete next steps: from quality plan to mock audit.
Book an intro call
