GxP Computerised System Validation: An Evidence-Lifecycle Guide

Validation is often represented as a list of documents. The list is useful only when the documents form a coherent evidence chain. A signed test protocol cannot compensate for an undefined intended use. A complete traceability matrix cannot make an unrepresentative test set representative. Supplier evidence cannot establish the behaviour of the customer's configuration and operating process by itself.

This guide explains the connected lifecycle. It does not prescribe a universal deliverable set, replace the applicable quality system or extend an FDA guidance beyond its stated scope.

Define the regulated reliance

State what the organisation will rely on the system to do. Name the users, process, regulated records or decisions, required outputs, operating conditions, interfaces and exclusions. Separate a capability from its intended use: the same reporting feature can support navigation, workload management or a release decision, with different consequences and evidence needs.

Set the GxP boundary around the end-to-end process, not the commercial product name. Include configured applications, identity services, interfaces, reports, migration tools, spreadsheets, manual hand-offs and procedures where they materially contribute to the relied-upon outcome. Record external services and supplier responsibilities rather than treating them as outside the boundary merely because the customer does not operate them.

EU GMP Annex 11 states that applications should be validated and IT infrastructure qualified, with lifecycle risk management considering patient safety, data integrity and product quality. It expects user requirements to describe required functions and be traceable. The exact evidence architecture remains an organisation's justified implementation decision.

Use risk to focus assurance

Assess credible failures against the intended use. Consider incorrect processing, unavailable functions, unauthorised access, incomplete or altered data, late interfaces, misleading reports, uncontrolled changes and procedures that do not match the system. ICH Q9(R1) supports science-based quality-risk decisions and proportionality of effort, formality and documentation.

For each material risk, identify:

• the failure and its initiating conditions;
• the regulated consequence;
• preventive and detective controls;
• who can detect the failure and when;
• evidence required to show the control works;
• residual risk and the accepting authority.

Do not turn risk scoring into false precision. The purpose is to decide what deserves specification, challenge, monitoring and documented acceptance.

Assess the supplier and service

Determine which supplier activities and evidence can be relied upon. Review relevant quality practices, development and release controls, security, incident handling, service continuity, subcontractors, change notification, data return and exit. For configurable software as a service, distinguish the supplier's product evidence from customer-specific configuration, data, roles, interfaces and procedures.

Veeva validation binders, for example, can be valuable evidence about the released product. They do not decide whether a customer's configured workflow, report or integration supports its intended use. Record the reliance rationale: which supplier evidence is accepted, how it was assessed and which customer evidence remains necessary.

Specify the required behaviour

User requirements should describe observable needs and controls without prematurely hard-coding a solution. Include data integrity, security, records, reports, interfaces, audit trails, electronic signatures, availability, backup, retention and regulatory outputs where applicable. Each requirement should have an owner, rationale, risk relationship, acceptance method and change history.

Design and configuration specifications should explain how the requirement is implemented. Capture consequential choices, assumptions, dependencies and rejected options where those matter to future change. A configuration export is not always an adequate specification: it may state values without explaining the rule or the reason.

Use a traceability model that links intended use and risks to requirements, design, tests, deviations and acceptance. Traceability is a navigation and coverage control, not proof by itself.

Cover data and records

Identify authoritative data, record ownership, creation and modification routes, metadata, audit history, retention and retrieval. Define how master and reference data are governed. For each interface, specify mapping, timing, failure handling, duplicate prevention and reconciliation. For reports, define the population, logic, security, refresh timing and the decision made from the output.

If legacy data are migrated, preserve scope, mappings, transformation rules, trial results, reconciliation, exceptions and approval. If records remain in an archive, demonstrate that they remain accessible, intelligible and protected for the required period. Validation must follow the record through the process, not stop where one application ends.

Design security and authority controls

Translate business roles and segregation rules into configured access. Address ordinary users, external users, integrations, administrators and emergency access. Test both permitted and prohibited actions in representative record states and populations. Review the combined access created by multiple roles.

Electronic approval evidence should establish identity, meaning, timing and the record or state approved. A visible approval field is not enough if the underlying evidence can change or if the approver cannot see the information required by the procedure.

Build a test strategy from claims

Define what each test is intended to establish. Select methods proportionate to risk and knowledge: supplier-evidence review, configuration inspection, scripted or unscripted functional testing, automated tests, interface reconciliation, security challenges, performance checks and user acceptance testing.

Cover normal processing, boundaries, invalid input, rejection, correction, unavailable dependencies, retries, alternate roles and recovery. Include realistic data volumes and process variants where they influence the outcome. Test the actual execution path: an on-screen result may not represent an exported report, scheduled interface or manual meeting pack.

Representative UAT should involve suitable users, permissions, records, hand-offs and operating conditions. It should answer whether the configured service supports the intended business process, not simply repeat technical tests with business signatures.

For each result retain the version, environment, identity, prerequisites, test data, expected behaviour, actual behaviour and evidence. Keep the supported conclusion no broader than the challenged conditions.

Control deviations and acceptance

Classify a test deviation before deciding its outcome. Distinguish a product or configuration defect, test-script error, data or environment issue, requirement ambiguity and acceptable observed difference. Assess which results and requirements are affected, correct the cause, repeat or extend testing as needed and preserve the rationale.

Open deviations at acceptance require explicit ownership and risk disposition. Do not hide them in a summary count. The validation summary should state scope, versions, executed evidence, deviations, residual risks, operational prerequisites, exclusions and the accountable decision to permit use.

Operational readiness belongs in acceptance. Procedures, training, support, monitoring, backup and restore, access administration, incident response, business continuity and record retention must be capable of operating on day one.

Establish the evidence baseline

At release, identify the controlled baseline: application and infrastructure versions, configuration, code, interfaces, reference data, procedures, approved requirements and specifications, executed evidence, known issues and accepted risks. Together, these define the accepted evidence state: the conditions under which the organisation has justified reliance on the system for its intended uses. Make clear where each record is stored and how the set can be reconstructed.

The baseline is not frozen forever. It is the known evidence state against which later changes, incidents, access changes, supplier changes and other events are assessed. The question is not only what changed, but whether the conditions supporting the prior reliance still hold.

Maintain the validated state

Change control should determine which intended uses, risks, requirements, design elements, records, procedures and evidence may be affected. Reuse unaffected evidence with a reason; produce new evidence where the prior basis may no longer hold. Supplier release information is an input to this customer decision.

Assess incidents for both service restoration and evidence impact. Establish the affected time window, records, controls and decisions, then determine whether retrospective review, targeted verification, correction or broader revalidation is needed.

Periodic review should examine the current state using relevant changes, incidents, access, audit-trail findings, interfaces, performance, procedures, training, supplier status, backups, continuity tests, unresolved risks and evidence debt. It should result in a disposition and owned actions, not merely a calendar signature.

Retire without losing the record

Plan retirement before the system becomes unsupported. Inventory records, metadata, attachments, relationships and audit history. Define retention, legal holds, access, readable representation, search and retrieval, security, migration or archive verification, and ownership after shutdown. Confirm that dependent interfaces, reports, procedures, accounts and licences are closed in a controlled sequence.

Decommissioning evidence should show not only that infrastructure was switched off, but that required regulated records remain complete, accessible and intelligible and that no live process still relies on the service.

A minimum coherent evidence map

The names vary, but the lifecycle should make these relationships visible:

Sources

• European Commission, EU GMP Annex 11: Computerised Systems (current 2011 revision): lifecycle risk management, requirements, validation, security, change, periodic evaluation, continuity and archiving.
• FDA, General Principles of Software Validation: software lifecycle and objective-evidence concepts within its stated scope.
• FDA, Computer Software Assurance for Production and Quality Management System Software: final February 2026 guidance for in-scope medical-device production and quality-management-system software; not presented as general pharmaceutical GMP authority.
• ICH Q9(R1), Quality Risk Management: science-based quality-risk management and proportionality.

The evidence map and lifecycle method are Navata practitioner interpretation. They organise source-backed expectations but are not prescribed document names.