Scope computer system validation around intended use

The vendor pack is an input to the assessment

A software supplier provides a large test pack and describes the product as validated. The site installs it with local roles, custom status mappings and an interface to the quality system. The supplier's tests do not cover those choices, yet the project treats the pack as proof that the local workflow is ready.

Computer system validation should establish that the system is fit for its intended use in the actual operating context. Supplier evidence can be valuable, but its relevance depends on what was tested, which version and configuration were covered and how the site will use the result.

The first deliverable is therefore a clear description of intended use. Name the users, activities, records, decisions, interfaces and operational boundaries. Without that definition, a test programme can become either excessively broad or dangerously superficial.

EU GMP Annex 11 links user requirements, risk assessment and lifecycle validation evidence. Use it where applicable to the site's activities; the local validation strategy must also address the relevant Indian and other market requirements. EU GMP Annex 11, validation.

Describe the decision the system supports

“Inventory management” is too broad to guide validation. “Prevent reservation of material that is not eligible for the intended production order using the authorised quality status” defines a consequential behaviour. It identifies the source of authority, the action being controlled and the result users rely upon.

Map the workflow from input to decision and retained record. Include manual steps, middleware and reports. A control performed outside the application can be part of the overall process, but it needs a defined owner and evidence rather than an assumption that someone will notice an error.

Classify functions according to their actual impact under the approved strategy. A decorative display and a status used to permit material consumption do not deserve identical treatment. The assessment should explain the difference and guide the evidence effort accordingly.

Establish the configuration and supplier basis

Inventory the application version, relevant modules, configuration, interfaces, infrastructure and external services. Identify which elements the supplier controls and which the site controls. A cloud deployment still has configuration and operational responsibilities that need ownership.

Review the supplier's development and support evidence to the extent appropriate for the intended use and risk. Determine which supplied tests can be relied upon and which site-specific evidence remains necessary. Record the rationale rather than either accepting or rejecting the entire pack without assessment.

Worked example of a released-stock interface

Consider an illustrative interface that sends authorised material status from a quality system to a warehouse application. The intended use is to support reservation only when the relevant lot and quantity are eligible. The normal test sends a released status and confirms that the correct lot becomes available.

That test is necessary but incomplete. A stale-status scenario disconnects the interface after a lot is placed on hold in the source system. The expected response should follow the approved requirement for unavailable or outdated status. The test checks that the warehouse does not treat old information as unconditionally current.

A duplicate-message scenario sends the same status event twice. The receiving system should preserve the correct state without duplicating a quantity or history event in a way that changes meaning. A sequencing scenario delivers an older released message after a newer hold message and checks that the obsolete event cannot restore eligibility.

The test evidence records inputs, configuration, expected behaviour, actual result and any deviation. If the system fails, the team assesses the defect, applies a controlled correction and verifies the affected behaviour. It should not rewrite the expected result to match what the software happened to do.

The example demonstrates why intended use matters. A supplier test proving that an API endpoint accepts a message does not establish that the site's reservation decision remains correct during stale, duplicate or out-of-order updates.

Use traceability to support reasoning

Connect requirements to relevant risks, controls and evidence. The connection should help a reviewer understand why a test exists and what conclusion it supports. A large traceability matrix filled with repeated identifiers is less useful if the relationships do not explain the risk.

Use evidence appropriate to the question. Some requirements are demonstrated through configuration review, supplier assessment or procedural verification; others need execution under representative conditions. Avoid treating the number of screenshots as a measure of validation quality.

For electronic batch records, the implementation guide provides workflow-specific questions. For record and signature applicability, use the Part 11 and Annex 11 assessment guide. The validation scope should connect these assessments rather than repeat them as disconnected paperwork.

Test operational readiness as well as functions

Confirm that the intended roles can perform authorised actions and cannot perform prohibited ones. Check the relevant record history, backup and recovery behaviour, retention access and support process. A workflow can pass its business tests while remaining difficult to operate or recover reliably.

Train users for the actual configuration and exception paths. A technical error should have an identifiable owner and a controlled response. If the only recovery knowledge sits with one developer, the operating model remains fragile even when the test evidence is complete.

Establish acceptance criteria for unresolved issues. The responsible reviewers need to understand their impact and any authorised controls before deciding readiness. A project deadline is not evidence that a defect is immaterial.

Keep validation current through change

Assess changes to configuration, integrations, infrastructure, procedures and intended use. A new report can become consequential if users start relying on it for a regulated decision, even when the underlying application code is unchanged.

The change-control impact guide explains how to identify those dependencies. Determine the verification needed for the change and preserve the rationale. Repeating every historical test may be unnecessary, while testing only the edited screen may miss affected behaviour elsewhere.

Periodic review should use operational evidence such as incidents, changes, access issues and performance against intended use. The appropriate scope and frequency follow the approved strategy. The goal is to identify whether the system remains fit for use and what action is needed.

Do not import another sector's assurance scope

Terminology such as computer software assurance can be useful, but the source and scope matter. FDA's February 2026 guidance concerns software used in medical-device production and quality-management systems. It should not be presented as a general exemption from validating drug-manufacturing or laboratory systems. FDA device software-assurance guidance.

For a drug site, select the applicable requirements and justified evidence approach for the actual use. Efficiency comes from focused reasoning and relevant evidence, not from changing the programme's label while omitting necessary work.

Summary and next actions

Validation should show that a configured system supports its intended use, including meaningful failures and operational controls. Supplier evidence contributes to that conclusion but does not automatically cover the site's local decisions and integrations.

• Define one consequential workflow, its authoritative inputs and the decisions users rely upon.
• Compare supplier evidence with the installed configuration and identify the remaining site evidence.
• Test normal operation, stale information, duplicate events and recovery against approved expectations.
• Assign lifecycle owners and connect future changes and operating incidents to the validation strategy.