GxP Validation for ERP Systems: What Your 2026 Validation RFP Must Require (CSV, IQ/OQ/PQ, Audit Trails)

A GxP validation RFP for an ERP system must require five things at minimum: a risk-based validation approach aligned with GAMP 5, explicit coverage of 21 CFR Part 11 and EU Annex 11 controls (electronic records, electronic signatures, audit trails), a full IQ/OQ/PQ execution plan with traceability from user requirements to test evidence, a defined strategy for keeping the system validated through patches and upgrades, and named deliverables with acceptance criteria for each — not "validation support" as a line item. RFPs that leave these as vague intentions get proposals that are impossible to compare and projects where validation scope is discovered, expensively, mid-implementation.

This guide is written for the people who own that RFP: quality and validation leads, IT quality managers, and procurement teams in pharmaceutical, biotech, medical device, and other GxP-regulated companies who are selecting an ERP platform or an implementation/validation partner in 2026. It explains the regulatory baseline as it applies to ERP specifically, walks through the IQ/OQ/PQ phases for an ERP rollout, and ends with a concrete requirements checklist you can lift directly into your RFP.

Key Takeaways

• GxP validation for ERP is risk-based, not exhaustive: GAMP 5 expects you to scale rigor to patient-safety and product-quality impact, and regulators have endorsed this direction through the FDA's Computer Software Assurance (CSA) thinking
• A configured commercial ERP is typically GAMP software category 4; any custom code (reports, interfaces, extensions) is category 5 and demands the highest test rigor
• 21 CFR Part 11 and EU Annex 11 both apply to ERP because ERP holds GxP records: batch and lot genealogy, inventory status, supplier qualification, training, and electronic approvals
• Audit trails must be secure, computer-generated, time-stamped, and capture who/what/when/old value/new value — and your RFP must demand they are reviewable in practice, not just present in a database
• IQ proves correct installation, OQ proves configured functions work as specified, PQ proves the system works in your actual business process with trained users
• The traceability matrix (URS → functional/configuration spec → test cases → results) is the deliverable an auditor asks for first; require it explicitly
• Validation does not end at go-live: require a periodic review cadence, change-control integration, and a re-validation strategy for vendor upgrades
• Vendor qualification (audit or assessment of the ERP vendor and the implementation partner) is your obligation, not the vendor's — build it into the RFP timeline

---

Why ERP Falls Squarely Inside GxP Validation Scope

It is tempting to think of ERP as "just business software" compared with LIMS, MES, or chromatography data systems. Auditors do not see it that way, because ERP routinely holds and processes records with direct GxP impact:

If your ERP performs any of these, it is a GxP-regulated computerized system and must be validated — meaning you need documented evidence that it does what it is intended to do, reliably and repeatably. That is the definition of computer system validation (CSV) that has anchored the discipline for decades, and it remains the foundation even as terminology evolves.

CSV, CSA, and What "Risk-Based" Actually Means in 2026

Two frameworks dominate the conversation:

GAMP 5 (second edition) — the industry's de facto methodology for validating computerized systems. Its core idea is proportionality: the depth of specification and testing should scale with system complexity and with risk to patient safety, product quality, and data integrity. GAMP 5 classifies software into categories that drive the validation approach:

A configured commercial ERP is category 4 — but almost every real ERP project also contains category 5 elements: custom label logic, an interface to a MES or LIMS, a bespoke batch-record report. Your RFP must require the vendor to classify every component and apply category-appropriate rigor, because the most common validation gap we see is custom interfaces tested to category-4 depth.

Computer Software Assurance (CSA) — the FDA's push, articulated in guidance work over recent years, to move the industry away from documentation-heavy testing of everything toward critical thinking: identify the features that touch patient safety and product quality, apply scripted testing there, and use leaner assurance activities (unscripted exploratory testing, leveraging vendor evidence) for lower-risk features. CSA does not replace validation and does not change Part 11; it changes how you spend your testing effort. A modern RFP should invite a CSA-informed approach — vendors still proposing 100% scripted testing of every screen are selling you 2010-era effort at 2026 rates.

The practical synthesis for your RFP language: "The validation approach shall be risk-based per GAMP 5, with documented risk assessment driving the assurance level per requirement, and shall incorporate Computer Software Assurance principles where consistent with our quality management system."

21 CFR Part 11 and EU Annex 11: The ERP-Relevant Requirements

Both regulations govern electronic records and computerized systems; if you operate in or sell into both the US and EU, you comply with both. As they apply to ERP:

Three ERP-specific traps worth writing into the RFP:

1. Audit trail reviewability. Many ERPs technically log changes but make review impractical — the trail lives in raw database tables or scattered logs. Regulators expect audit trail review to be a real, periodic activity for high-risk records. Require the proposal to demonstrate how a QA reviewer would actually review the audit trail for, say, all changes to lot status in a month.
2. Time synchronization and time zones. Multi-site deployments must produce unambiguous time stamps. Require the proposal to state the time source and time zone handling for audit trails.
3. Hybrid records. If any process remains paper-plus-electronic (a printed pick list signed by hand), the proposal must define how the hybrid record set is controlled. Undefined hybrids are a classic audit finding.

IQ, OQ, PQ for an ERP Rollout

The qualification phases map onto an ERP project as follows:

Installation Qualification (IQ)

IQ proves the system is installed correctly per specification in the environment where it will run.

For ERP this covers: server/cloud environment specification and verification, ERP application version and build, database version, installed modules and their exact versions, environment configuration (production vs. test segregation), backup configuration, and — often forgotten — verification that the validated configuration baseline is what actually got deployed to production. For cloud/SaaS ERP, IQ leans on the vendor's qualification of their infrastructure plus your verification of tenant-level configuration; your RFP should require the vendor to state exactly which IQ evidence they provide versus what you must generate.

Operational Qualification (OQ)

OQ proves that configured functions operate according to the functional and configuration specifications, exercised against defined acceptance criteria. ERP OQ test themes typically include:

• Security and access: role permissions enforce the documented authorization matrix; segregation of duties holds (the person who creates a PO cannot approve it, where so designed)
• Workflow state enforcement: quarantined stock cannot be issued to production; a lot cannot ship without released status
• Electronic signature behavior: signature prompts, manifestation, and audit linkage on each signed transaction type
• Audit trail capture: create/modify/delete events on in-scope records capture user, timestamp, old and new values
• Calculations: expiry date derivation, retest scheduling, FEFO picking logic, batch quantity reconciliation
• Alerts and operational checks: mandatory fields, value range checks, permitted step sequencing
• Interfaces: every custom interface (category 5) tested for correct data mapping, error handling, and failure recovery

Performance Qualification (PQ)

PQ proves the system performs reliably in your actual business process, with trained users, real-life data volumes, and your SOPs. Good ERP PQ looks like end-to-end scenario runs: receive material → quarantine → QC disposition → release → issue to manufacturing order → produce → final disposition → ship, executed by the people who will do it daily, under the procedures that will govern them. PQ is also where you prove record retrieval: pull the full electronic batch trail for a scenario lot and confirm it is complete and human-readable.

A phase-gate structure your RFP should mandate:

Staying Validated: The Part Most RFPs Forget

Initial validation is a project; the validated state is a lifecycle. Modern ERPs — especially cloud-delivered ones — receive vendor updates on a cadence you do not fully control. Your RFP must require the bidder to propose:

• Change control integration — how configuration changes, patches, and new modules flow through your change control with risk-assessed regression testing
• Vendor release strategy — advance notice of releases, what vendor regression evidence is supplied, and a defined window to test before production uptake (for SaaS, ask pointedly: can updates be deferred? If not, what is the compensating assurance approach?)
• Periodic review — a scheduled (commonly annual) review of system performance, deviations, audit trail review status, access reviews, and cumulative change impact
• Re-validation triggers — defined criteria for when a change demands partial or full re-qualification

How Odoo-Based Systems Approach Validation

Open-source ERP platforms such as Odoo are increasingly evaluated by GxP companies — typically mid-size pharma distributors, medical device manufacturers, nutraceutical and cosmetics companies under GMP-adjacent regimes, and CDMOs modernizing from spreadsheets. The validation logic is identical: Odoo configured for your process is a GAMP category 4 system, and custom modules or interfaces are category 5. Points specific to the Odoo route:

• Vendor assessment looks different. With a proprietary mega-vendor you audit the vendor's quality system. With open source, the assessment shifts to the implementation partner's quality system and development lifecycle — their version control, code review, testing discipline, and release management become the auditable QMS. Require evidence of all four in the RFP.
• Source-code access is an asset. Category 5 components can be subjected to genuine code review and structural verification, which is often impractical with closed platforms.
• Part 11-relevant capabilities must be specified, not assumed. Odoo provides chatter-based change tracking, role-based access control, and workflow states out of the box, but a GxP deployment typically adds hardened field-level audit trail modules, electronic signature manifestation, and stricter password/account policies. Your URS must call these out explicitly so they are configured, documented, and tested — this is standard scoping work for an experienced partner, not a platform limitation, but it does not happen by default.
• Version upgrade discipline matters more. Odoo's annual major releases mean your validation lifecycle plan must address upgrade qualification head-on: a documented regression pack rerun against each upgraded environment before cutover.

If you are earlier in the journey — still selecting a platform rather than writing the validation RFP — our ERP implementation guide for pharmaceutical companies covers the platform-selection stage, and our Odoo consultancy team runs URS and validation-scoping workshops for regulated deployments.

The RFP Requirements Checklist

Lift this table into your RFP as a mandatory response matrix. Require bidders to respond per row with: Comply / Partially comply / Do not comply, plus a reference to where their proposal evidences it.

Scoring tip: weight rows 6, 10, 11, 12, 19, and 21 highest. Traceability, the two regulatory mappings, demonstrable audit trail review, the upgrade strategy, and the partner's own quality system are where weak bidders fail and where project pain concentrates.

Common Failure Modes to Screen Out

• "Validation documentation pack included" with no execution scope — paper templates are not validation; testing and evidence are.
• All testing scripted, none risk-prioritized — signals a checkbox shop that will burn your budget on low-risk screens.
• No named approach for category 5 interfaces — the highest-risk components quietly excluded from the highest rigor.
• PQ written and executed entirely by the vendor — PQ belongs to your users and your SOPs; a vendor-only PQ proves little.
• Silence on staying validated — if the proposal ends at go-live, so does your compliance.

Frequently Asked Questions

What is the difference between CSV and CSA, and which should my RFP require?

CSV (computer system validation) is the established discipline of producing documented evidence that a system fulfils its intended use. CSA (computer software assurance) is the FDA-encouraged evolution of how you do it: apply critical thinking and risk assessment first, concentrate scripted testing on features affecting patient safety and product quality, and use leaner assurance methods elsewhere. They are not alternatives — your RFP should require validation per GAMP 5 executed with CSA-informed, risk-based test planning. Avoid vendors who treat CSA as a buzzword for "less documentation" without a documented risk rationale.

Is an ERP system really subject to 21 CFR Part 11?

Yes, wherever the ERP creates, modifies, maintains, or transmits electronic records required by predicate GxP rules — which a manufacturing or distribution ERP almost always does: lot genealogy, inventory dispositions, approved supplier records, electronic approvals. Part 11 then governs the electronic records and signatures involved: validation, audit trails, access controls, and signature requirements. The same logic brings EU Annex 11 into scope for operations under EU GMP. The scoping exercise in your URS should tag exactly which records and signatures are GxP-relevant so testing concentrates there.

Do we validate the whole ERP or only the GxP-relevant parts?

Risk-based validation means you qualify the system but concentrate rigor on GxP-impacting functionality. In practice: the validation plan covers the system as a whole (installation, security, audit trail infrastructure), while requirement-level test depth is driven by the risk assessment — full scripted testing for lot status control and e-signatures, leaner verification for, say, a CRM module with no GxP role. The critical artifact is the documented risk assessment justifying each decision; "we did not test it" is defensible only when "because risk assessment X classified it non-GxP" follows.

How long does ERP validation add to an implementation timeline?

For a mid-size GxP deployment, expect validation activities to add roughly 25–50% to the implementation effort, depending on how much custom (category 5) work exists and how mature your URS is at the start. Planning and specification run partly in parallel with configuration; IQ/OQ typically add weeks, and PQ depends on how quickly your trained users can execute end-to-end scenarios. The biggest schedule killer is a late, vague URS — requirements discovered during OQ force spec rework and re-testing. Investing in a rigorous URS workshop before configuration starts is the single best schedule protection.

Can a cloud or SaaS ERP be GxP-validated?

Yes — many are. The shift is in responsibility split: the provider qualifies the infrastructure and platform layers (and should evidence this via certifications and audit reports your vendor assessment reviews), while you remain responsible for validating your intended use: configuration, workflows, signatures, audit trails, and data. The hard questions for SaaS are update control (can you defer releases? what regression evidence ships with each?), data retrieval through the retention period, and exit terms. Put all three in the RFP as mandatory response items.

How does Odoo compare to traditional pharma ERPs for validation effort?

The validation methodology is identical — GAMP category 4 core plus category 5 custom components, same Part 11/Annex 11 mappings, same IQ/OQ/PQ structure. The differences are practical: Odoo deployments usually need explicit hardening for field-level audit trails and signature manifestation (scoped in the URS), the vendor assessment focuses on the implementation partner's development quality system rather than a mega-vendor's, and source-code access makes genuine code review of custom components feasible. Total validation effort lands in a similar range; the platform cost difference is where the budgets diverge. Our pharma ERP implementation guide covers the selection trade-offs in depth.