Matrix: GxP System Category Comparison and Selection

This matrix supports two decisions that come up constantly once you understand the system-type map and start acquiring or reassigning function among systems. Part A scores candidate vendor products against each other within one category, for example comparing three LIMS vendors during a selection project. Part B decides which category a borderline function belongs in, for example whether an in-process trending calculation should live in the MES, the process historian, or a spreadsheet. The two decisions use different criteria, so they are kept separate rather than forced into one table. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows each part. This is educational structure to adapt, not legal or regulatory advice.

Document control header

Field	Entry
Document title	GxP System Category Comparison and Selection Matrix
Document number	`<<FILL: reference, e.g. MTX-CSV-2026-01>>`
Prepared by	`<<FILL>>`
Date	`<<FILL>>`

Part A: comparing candidate systems within one category

A1. Scoring criteria

Criterion	Question it answers	Scale
Functional fit	Does the candidate perform the GxP-relevant functions your requirements call for, without heavy custom development?	Strong / Partial / Weak
Audit trail depth	Does it capture user, timestamp, old value, and new value for every GxP-relevant change, and can that capture be prevented from being disabled by an ordinary user?	Strong / Partial / Weak
Electronic signature support	Does it natively support a Part 11/Annex 11-style signature manifestation (printed name, date, time, meaning), or does that require custom configuration on top?	Native / Configurable / Not supported
Likely GAMP category	Based on how much configuration or customization reaching your requirements will take, where does this candidate land?	3 / 4 / 5
Vendor quality maturity	Does the vendor run a credible quality system with documented testing evidence you can review and rely on to reduce your own testing burden?	High / Medium / Low
Integration capability	Does it offer a documented, supported interface to the specific other systems this category typically connects to?	Native / Middleware needed / Not available
Deployment model	On-premise, private cloud, or multi-tenant SaaS, and what that means for your validation and data-residency approach	`<<FILL: describe per candidate>>`
Total validation effort estimate	Realistically, how much validation effort, not license cost, does this candidate demand to reach a defensible state?	Low / Medium / High

A2. Comparison worksheet

Candidate	Functional fit	Audit trail depth	E-signature support	Likely GAMP cat.	Vendor maturity	Integration capability	Deployment model	Validation effort	Overall recommendation
`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`

Part B: deciding which category a borderline function belongs in

Some functions do not obviously belong to one category. A calculation could live in the MES as a configured step, in the process historian as a derived tag, or in a spreadsheet someone builds because it is faster than requesting a change to either validated system. This part scores that decision so it does not default to whichever route is easiest this week.

B1. Scoring criteria

Criterion	Question it answers
GxP decision weight	Does this function’s output, on its own, drive a release, disposition, or patient-safety decision, or does it only support a decision already made elsewhere?
Calculation/logic complexity	Is this a simple pass/fail comparison, or a multi-step calculation with branching logic and multiple inputs?
Change frequency	Does the underlying logic change often, which favors a category that revalidates easily, or rarely, which tolerates a heavier validation approach?
Existing category capacity	Does an already-validated system in a candidate category have the configured capacity to absorb this function without a disproportionate change?
User / reach scope	Is this a single-user convenience calculation, or something many roles across shifts or sites depend on?

B2. Boundary decision worksheet

Candidate category	GxP decision weight	Logic complexity	Change frequency	Existing capacity	User/reach scope	Rationale
`<<FILL: e.g. MES>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
`<<FILL: e.g. Process historian>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
`<<FILL: e.g. Spreadsheet>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`

Acceptance criteria

Every candidate in Part A is scored against all eight criteria, not just the ones that make the preferred candidate look best.
The likely GAMP category and validation effort estimate in Part A are stated with enough detail that the eventual validation plan can be scoped from them.
Every candidate category in Part B is scored against all five criteria before a recommended home is chosen, and the rationale column states why the losing candidates were rejected, not only why the winner was picked.
A function scored in Part B as high GxP-decision-weight and high reach never lands in a spreadsheet by default; that combination gets flagged for a validated-system home even if it costs more effort.
The completed matrix is retained with the selection or classification decision it supported, so the reasoning survives staff turnover.

References

ISPE GAMP 5 (Second Edition) for the software-category concept behind the GAMP category criteria. 21 CFR Part 11; EU GMP Annex 11, for the audit trail and signature criteria in Part A. Related reading: GxP computerized systems, a complete map for the five-questions framework and the category tour this matrix draws its criteria from.

Confirm the current version of each reference before issue.

Revision history

Version	Date	Author	Summary of change
`<<FILL: 1.0>>`	`<<FILL: date>>`	`<<FILL: author>>`	Initial issue.

Approvals

Role	Name	Signature	Date
Author	`<<FILL>>`
Approver (Validation/QA)	`<<FILL>>`

Filled specimen

Part A specimen: comparing three LIMS candidates

Candidate	Functional fit	Audit trail depth	E-signature support	Likely GAMP cat.	Vendor maturity	Integration capability	Deployment model	Validation effort	Overall recommendation
Vendor 1	Strong	Strong	Native	4	High	Native to CDS and ERP	Cloud, single tenant	Medium	Preferred: strongest audit trail depth and native e-signature reduce configuration risk
Vendor 2	Strong	Partial (old/new value not captured for limit-table edits by default)	Configurable	4	Medium	Native to CDS, middleware needed for ERP	On-premise	High	Rejected: limit-table audit gap is the exact failure mode the category profile flags as a common finding
Vendor 3	Partial (heavy customization needed for disposition workflow)	Strong	Native	5	High	Native to CDS and ERP	Cloud, multi-tenant	High	Rejected: customization depth pushes this to Category 5, more validation effort than the gain over Vendor 1 justifies

Candidate category	GxP decision weight	Logic complexity	Change frequency	Existing capacity	User/reach scope	Recommended home	Rationale
MES	High, the OOS flag can trigger a deviation	Low, single threshold comparison	Low, threshold rarely changes once qualified	MES already runs limit checks for other in-process parameters	Every operator on every batch	Recommended	High decision weight and existing configured capacity for limit-check logic make the MES the defensible home
Process historian	High	Low	Low	Historian already holds the raw pH tag	Every batch, but not operator-facing	Not recommended alone	The historian can hold the tag, but it should not be the sole system flagging an OOS condition without MES-level workflow and signature
Spreadsheet	High	Low	Low	None, would be built from scratch	Whoever built it, likely one shift	Rejected	High decision weight plus wide reach is exactly the combination that should never default to a spreadsheet regardless of how simple the calculation looks

The recommendation lands the function in the MES specifically because the decision weight is high and an already-validated system has the configured capacity to absorb it; the spreadsheet route is rejected on the same two facts that would otherwise make it tempting: it looks simple, and someone could build it by Friday.

Common inspection findings this matrix prevents

A vendor selected on price or a sales demo, with the audit trail and e-signature gaps discovered only after go-live, when replacing the choice is expensive.
A GxP-critical calculation quietly living in a spreadsheet because building it there was faster than requesting a validated-system change, with no record that the category decision was ever actually made.
Two candidates scored informally in a meeting with no retained rationale, so a later reviewer or auditor cannot see why one was chosen over the other.
A function’s category re-litigated from scratch every time it comes up, because no one criterion set exists to settle it consistently.

How to adapt this matrix

Set your document number and date, and identify which parts apply: Part A, Part B, or both.
For Part A, pull your functional requirements from the relevant user requirements specification rather than re-deriving them here.
For Part B, be honest about decision weight and reach; the temptation is always to underrate both in favor of the fastest available system.
Retain the completed matrix with the selection record or the system inventory entry it supports.
Confirm every regulation referenced against its current published version before issue.