GAMP 5 Category 4 Validation: What Your CDM Software Vendor Should Provide

The GAMP 5 framework classifies software used in regulated pharmaceutical environments into five categories based on complexity and risk. Category 4 covers configured products — software that performs critical GxP functions and requires user configuration to meet specific requirements. Most clinical data management platforms, including EDC systems and CDM pipeline software, fall into Category 4. The validation activities required for Category 4 software are well-defined in the ISPE GAMP 5 guide. What is less well-defined — and where most pharma companies spend 3–6 months on unnecessary work — is what the software vendor should provide versus what the end user must produce.

The Vendor/User Validation Responsibility Split

The fundamental principle of GAMP 5 is that validation effort should be proportionate to risk and that work already done by the vendor should not be duplicated by the end user. For Category 4 software, this means:

Vendor responsibility: The software vendor should provide evidence of design qualification (DQ), installation qualification (IQ) documentation for the standard installation, and operational qualification (OQ) testing documentation covering the standard platform functionality. This is often called the "vendor validation package" or "vendor GAMP documentation."

End user responsibility: The pharmaceutical company or CRO uses the vendor's documentation as a foundation and adds performance qualification (PQ) testing that validates the specific configured system in the specific environment (production instance, study-specific validation rules, data flows) against the specific intended use.

In practice, many pharma companies do not request or receive adequate vendor validation packages, and their quality assurance teams then require the IT or CDM group to produce documentation that the vendor should have provided. This is the source of the 3–6 month CSV overhead that teams frequently report for new CDM software deployments.

The Minimum Validation Package a CDM Software Vendor Should Provide

Before signing a software license agreement for a Category 4 CDM platform, the following documentation should be a contractual requirement:

1. Vendor Audit Certificate or Quality Agreement. A document certifying that the vendor's own software development process is conducted under a quality management system appropriate for GxP-related software. This is usually ISO 9001 certification, FDA Software as a Medical Device QMS evidence, or a formal quality agreement. Without this, the end user's QA team cannot use the vendor's validation documentation as a reliable input to their own assessment.

2. Product Design Specification or Functional Risk Assessment. A document describing the software's critical functions, the risk classification of each function, and how the design addresses each identified risk. For a CDM platform, critical functions include data extraction accuracy, transformation rule execution, audit trail generation, access control enforcement, and data export integrity.

3. Installation Qualification Protocol and Evidence. A documented protocol for installing the software in a standard environment, with execution evidence (screenshots or test records) demonstrating that a standard installation produces a correctly functioning system. This may be cloud-hosted deployment documentation rather than traditional on-premises IQ documentation for SaaS CDM platforms.

4. Operational Qualification Test Scripts and Evidence for Core Functions. Test scripts that verify the software's standard functions work as specified, with execution records. At a minimum, these should cover: data ingestion from standard EDC APIs, validation rule execution, query generation, audit trail recording, dataset export, and access control. The end user needs to review these rather than reproduce them from scratch.

5. User Requirements Specification Template. A template or starter document the end user can use to document their specific configured use of the platform. A good vendor provides this as a starting point rather than requiring the end user to produce it from a blank page.

6. Change Control and Patch Management Documentation. A description of how the vendor manages software changes, patch releases, and version updates, including the notification process for end users and the impact assessment for validation status. End users need to know that a software patch does not automatically invalidate their validation without understanding what changed.

What End Users Must Still Produce

Even with a complete vendor package, end users cannot entirely outsource validation. The components that require end-user production:

Performance Qualification (PQ) testing for configured functions. The vendor's OQ covers standard platform functionality. PQ must cover the specific configuration: the custom validation rules deployed for a specific study, the specific EDC connections, the specific SDTM domain mappings. These are user-specific and cannot be pre-validated by the vendor.

User acceptance testing (UAT) with representative test data. Before deploying a CDM platform in production on a live study, the system should be tested with representative data — simulated patient-level data that exercises all configured validation rules, edge cases, and expected data patterns. Many teams skip this or perform it with inadequate test data coverage and then discover configuration problems during the first live reconciliation cycle.

Validation summary report tying vendor documentation to user configuration. The end user's validation package needs to demonstrate the logical connection between the vendor's baseline documentation and the user's specific deployment. A validation summary report or validation plan traceability matrix serves this function.

Training records for all system users. Part 11 and GAMP 5 both require that personnel using the system are qualified to do so. Training records for system users must be maintained by the end user organization, not the vendor.

Common Gaps in Vendor Documentation

In our experience across multiple CDM software implementations, the most common gaps in vendor validation packages are:

• Incomplete audit trail test coverage. Vendors often provide OQ evidence for audit trail creation but not for audit trail immutability or accessibility. As discussed in our article on 21 CFR Part 11 audit trail requirements, immutability and accessibility are the attributes most commonly cited in inspection findings.
• Missing access control segregation testing. OQ documentation covers that access control features exist but does not always include test cases demonstrating that unauthorized access attempts are properly rejected. This matters when FDA inspectors review system access logs.
• No version comparison documentation. When a vendor releases a new version, the documentation comparing the new version's validation status to the previous version is often absent. End users cannot determine which of their existing PQ test cases remain valid after an upgrade without this documentation.
• Cloud infrastructure documentation gaps. SaaS CDM platforms hosted on cloud infrastructure (AWS, Azure) need to address how the cloud provider's shared responsibility model interacts with the validation requirements. Many vendor packages do not clearly document this boundary.

Negotiating Validation Package Requirements

The time to negotiate validation documentation is before contract signature, not after deployment. Include in the software license agreement:

• A list of required validation documents with acceptance criteria
• A commitment from the vendor to provide updated validation documentation within 30 days of each software release
• Audit rights for the vendor's QMS (typically exercised annually or when a significant software issue occurs)
• Notification requirements for changes that affect validation status

MLPipeKit provides a complete GAMP 5 Category 4 validation package as a standard deliverable for all licensed customers, including all six components described above and a customer-specific validation summary template pre-populated with the platform's core functions. The PQ and UAT phases are still the customer's responsibility, but the vendor-side documentation that most CDM platforms do not provide is delivered before go-live.