“EPA Inspectors Don’t Ask for Validation Documentation.” Why Do It Anyway?
The GLP Answer: Data Integrity (and why “software verification” alone can create false comfort)
Xevalics Consulting, LLC
Who This Is For
This post is for:
- GLP QA leaders, Study Directors, lab IT, and data integrity owners working in test facilities using computerised systems.
- CROs running GLP studies and managing audit and inspection readiness across ELN, LIMS, CDS, and instrument platforms.
- Sponsors outsourcing GLP work to CROs and test facilities who need confidence that study data is trustworthy, traceable, and retrievable, including during archiving and retrieval.
- Teams moving from on-prem to cloud and SaaS ELN, LIMS, CDS, or modern data services.
Introduction
Many GLP teams prefer the term “software verification” because it feels lighter than “CSV.” Some also observe that EPA inspections do not always begin with a request for a validation binder. That combination can lead to an understandable question: Why validate at all? This is exactly where computerized systems GLP data integrity either holds up—or fails. This is why computerized systems GLP data integrity must be demonstrated in real operations.
OECD GLP guidance for computerized systems is not built around binder production. It is built around maintaining data integrity through the validated operation of computerized systems, scaled by risk and sustained through the system lifecycle. In practice, the uncomfortable truth is this: verified software can still produce unreliable GLP data if the broader system (people, SOPs, infrastructure, suppliers, and agreements) is not controlled. [1]
This article lays out a right-sized approach: lean evidence and strong control, so you avoid documentation waste and avoid data credibility risk.
Key Takeaways
- Inspectors not asking for validation binders does not make system control optional.
- Software verification can confirm functionality, but it does not prove the computerized system is in control.
- Most GLP data failures are operational: access, training, audit trail review, change control, backup and restore, interfaces, and archiving.
- CSA does not replace CSV. It modernizes how software assurance evidence is generated, while system validation and assurance remains broader. [4]
- Sponsors and CROs share risk: weak computerized system control becomes a study credibility problem fast.
- A minimum viable, risk-based evidence pack can be OECD-aligned and lightweight enough to sustain. [1]
- Computerized systems GLP data integrity depends on controlled operation, not just software tests.
GLP Sponsor and CRO Reality: Validation Is a Shared Risk
In GLP outsourcing, CROs and test facilities operate the systems, but sponsors rely on the outputs for regulatory decisions and business-critical conclusions. “Software verified” is rarely what sponsors are truly asking for. They want confidence that the operating environment is controlled and defensible.
This confusion typically surfaces during sponsor audits, study start readiness reviews, technology transfers, or when results are questioned. The fastest way to lose trust is not a missing document. It is data that cannot be reconstructed, explained, or retrieved.
The Inspector Paradox: Why They May Not Ask (Until Something Looks Off)
1) Why validation evidence isn’t always requested upfront
Inspections frequently focus on study conduct, raw data, deviations, and reporting. Computerised systems evidence may not be requested early unless there is a reason to probe deeper.
2) Common triggers for deeper probing
- Inconsistencies, unexplained changes, missing traceability, or access anomalies.
- Reprocessing without justification, suspicious edits, or weak audit trail review practices.
- Retrieval or archival issues, backup and restore weaknesses, or unclear system boundaries.
3) The point
Validation is not about predicting an inspector’s request list. It is about ensuring the system can withstand scrutiny when data credibility is questioned. [1]
Definitions That Prevent Confusion
Software verification
Component-level assurance that configured software meets specified requirements (tests and checks, often leveraging supplier evidence).
Computerised system validation and assurance (GLP)
System-level confidence that the full computerised system is fit for intended use in the GLP process and remains controlled over its lifecycle, including SOPs, training, access, infrastructure, suppliers, and change control. OECD Advisory Document No. 17 frames this as a scalable lifecycle approach focused on data integrity. [1]
“CSV” (without the drama)
CSV is a widely used industry label for validating and controlling computerised systems. The term varies by sector, but the underlying expectation remains: fit for intended use, controlled operation, and lifecycle governance. [1]
The CSA Paradox: Why “CSA Replaces CSV” Is a Misleading Understanding
1) Why the misconception happens
Teams hear “CSA is lighter than CSV” and interpret it as a replacement. That interpretation creates a gap: the software may be tested efficiently, while the operational control layer is underbuilt.
2) What CSA really is (in practice)
FDA’s Computer Software Assurance (CSA) guidance promotes a risk-based approach to establish confidence in software used in production and quality management system software, focusing evidence on what matters most. [4]
3) What CSA does not remove
CSA does not remove the need to ensure the whole computerised system (and its operating environment) is controlled.
Clean relationship statement:
CSA is risk-based software assurance and testing. It helps you generate evidence efficiently. [4]
System validation and CSV ensures the whole computerised system (people, SOPs, infrastructure, suppliers, and contracts) is fit for intended use and stays in control across the lifecycle. [1]
Where “Software Verification Only” Breaks Down in GLP
1) People, roles, and training
- Software can be correct while users are untrained or roles are unclear.
- Weak role definitions and access approvals create silent risk.
2) SOPs and process control
- No SOP for audit trail review means changes can occur without detection.
- No clear linkage between system events and deviations means issues can be mishandled or missed.
3) Infrastructure and environment
- Having backups is not the same as having proven restores.
- Uncontrolled patches and upgrades can break the validated state.
4) Interfaces, data transfers, and hybrid workflows
- Manual transcriptions, exports and imports, instrument integrations, and middleware are common failure points.
- Reconciliation rules and responsibilities must exist and be followed.
5) Suppliers, outsourcing, and Quality Agreements (Sponsor and CRO)
- Vendor and cloud responsibilities should be explicit (retention, security, availability, and change notification). [2]
- Sponsor and CRO agreements should define data ownership and access, audit rights, retention and archival responsibilities, incident notification timelines, and change notification expectations.
- Responsibilities should be unambiguous for key controls (audit trail review, backup and restore, user access administration, and periodic review).
The Evidence Map for Computerized Systems GLP Data Integrity
Use this as a practical map for what “controlled operation” means beyond software tests. [1]
| Control Area | Common Failure Mode | What Software Verification Covers | What System Control Requires | Minimum Lean Evidence |
|---|---|---|---|---|
| User access and roles | Unauthorized changes or weak segregation of duties | May test role features in software | Provisioning and deprovisioning workflow, approvals, periodic review | Access SOP, role matrix, and sample access records |
| Audit trails (generation and review) | Changes occur without detection or escalation | May verify audit trail exists and records events | Defined review frequency, triggers, responsibilities, escalation | Audit trail review SOP and evidence of review |
| Change control and configuration management | Uncontrolled configuration changes, loss of validated state | May test configured functions at a point in time | Change evaluation, approvals, testing scope, release records | Change SOP, sample change records, and release notes |
| Backup and restore | Backups exist but restore fails, incomplete recovery | Usually not addressed by software-only testing | Restore testing, recovery objectives, responsibilities | Backup and restore SOP with restore test evidence |
| Archiving and retrieval | Records cannot be retrieved promptly or fully with metadata | May verify export or archive function exists | Retention rules, retrieval testing, integrity checks | Archive SOP with retrieval test evidence |
| Interfaces and data transfers | Missing reconciliation, silent data loss or duplication | May test a transfer works in a happy path | Reconciliation rules, error handling, ownership of checks | Data flow map, reconciliation procedure, sample records |
| Supplier oversight and cloud responsibilities | Unclear responsibility for security, retention, change notifications | Often outside software test scope | Supplier assessment, service level commitments, change notification, periodic review | Supplier assessment, service level highlights, and change notice examples |
| Sponsor and CRO Quality Agreement | Misaligned expectations, gaps in access, retention, audit rights | Not addressed by software-only testing | Clear responsibilities, audit rights, notification timelines | Responsibility matrix and quality agreement clauses summary |
Minimum Viable Controlled-System Pack
This is a practical, right-sized evidence pack aligned to OECD expectations for computerised systems in GLP, scaled by risk. [1]
- Intended use and GLP impact statement.
- System overview with data flow and interfaces (where data is created, processed, transferred, and archived).
- Risk assessment focused on integrity, availability, and traceability.
- Supplier assessment with reliance rationale (including SaaS responsibilities where applicable). [1] [2]
- Critical function testing summary (risk-based; not “test everything”).
- SOP set: operation, administration, access, change control, backup and restore, audit trail review, incident handling.
- Training plan with role authorization evidence.
- Go-live readiness checklist (include cutover and migration controls if relevant).
- Periodic review and continued assurance plan.
- Sponsor and CRO evidence outline (what the CRO can show during sponsor audits without creating unnecessary burden).
What Inspectors (or Any Auditor) Can Probe When Data Credibility Is Questioned
- What GLP decisions or records does this system influence, and what is the intended use boundary?
- Who can change configurations, methods, or master data, and how is that authorized and logged?
- Can you reconstruct a specific record: who did what, when, why, and under what version and configuration?
- Who reviews audit trails, how often, and what triggers escalation?
- Do you have objective evidence that restore works (not just that backups run)?
- Can you retrieve archived records promptly and completely, including metadata?
- For outsourced studies: what does the Sponsor and CRO Quality Agreement say about data access, retention, audit rights, and notifications?
- How are system changes communicated and assessed during ongoing studies?
Frequently Asked Questions
Is computerised system validation required for GLP computerised systems?
OECD Advisory Document No. 17 provides guidance for applying GLP principles to computerised systems using a lifecycle, risk-based approach focused on data integrity. [1]
Is software verification enough for GLP?
Software verification is useful evidence of functional correctness, but it does not cover the operational controls required to keep the full system in control (people, SOPs, access, change control, backup and restore, audit trail review, and archiving). [1]
What is the minimum documentation set that still protects data integrity?
A right-sized evidence pack should cover intended use, risk, critical function testing, SOP controls, training and access governance, backup and restore, audit trail review, archiving and retrieval, and continued assurance. [1]
Does CSA replace CSV?
No. CSA is a risk-based approach to software assurance and testing evidence. System validation and assurance remains broader and includes the full operating environment and lifecycle governance. [4] [1]
Can we leverage vendor documentation and testing?
Often yes, especially for mature commercial off-the-shelf or SaaS systems, provided you document reliance rationale and still verify what matters for your intended use and GLP risks.
What changes when ELN, LIMS, or CDS moves to the cloud?
Responsibilities shift, but they do not disappear. OECD’s cloud supplement is intended to help test facilities apply GLP expectations in cloud models, including responsibility clarity, security, availability, retention, and change notification. [2]
What should a sponsor require from a CRO for GLP computerised system control?
Clear evidence that the CRO can operate and maintain the system in a controlled state: defined responsibilities, audit trail review, access control governance, backup and restore evidence, archiving and retrieval proof, change control, and incident notification expectations. [1]
What should be in a sponsor and CRO Quality Agreement for ELN, LIMS, or CDS under GLP?
At minimum: data ownership and access, audit rights, retention and archival responsibilities, incident notification timelines, change notification expectations, and a responsibility matrix for key system controls.
Conclusion
If inspectors do not ask for validation binders, that does not mean validation is wasted. It means success is measured where it counts: data integrity, traceability, reliability, and defensible archiving. [1]
Software verification supports confidence in functionality. System validation and assurance protects the real GLP risks: people, procedures, infrastructure, suppliers, agreements, and lifecycle control. [1]
Xevalics’ contribution is the practical middle: lean evidence and strong control, built to withstand scrutiny when the data matters most.
About Xevalics Consulting
Xevalics Consulting, LLC supports regulated organizations with digital quality, data integrity, computerised system assurance, supplier governance, and audit readiness, focused on systems that remain controlled through real operations, not just at go-live.
Our focus is the qualified, controlled, and auditable operation of regulated digital systems across GLP and broader GxP environments without compromising scientific integrity or regulatory expectations.
Transparency Statement
This article was developed with the assistance of artificial intelligence tools to support research synthesis, drafting, and editorial refinement. Human subject-matter expertise guided all analytical decisions. Xevalics Consulting, LLC retains full responsibility for the content and perspectives expressed.
Regulatory and Compliance Disclaimer
This article is provided for informational and educational purposes only and does not constitute regulatory guidance, legal advice, or an official interpretation of applicable laws, regulations, or guidance documents. Organizations remain solely responsible for determining regulatory applicability and compliance.
Works Cited
- OECD. Application of GLP Principles to Computerised Systems (Advisory Document No. 17; ENV/JM/MONO(2016)13).
PDF - OECD. Advisory Document on GLP and Cloud Computing (Supplement 1 to No. 17; ENV/CBC/MONO(2023)27).
PDF - OECD. OECD Position Paper on Good Laboratory Practice and IT Security (OECD Series on GLP and Compliance Monitoring No. 25; 2024).
PDF - FDA. Computer Software Assurance for Production and Quality Management System Software (Guidance).
Web page - eCFR. 21 CFR § 11.10(a) (validation of systems language in the electronic records context).
Web page
