The V-model for a computerised system: where SIT and UAT sit next to IQ, OQ and PQ

Kick-off meeting for a new laboratory information management system (LIMS). The IT project manager presents a plan built around SIT and UAT. Quality assurance (QA) asks where the IQ, OQ and PQ are. The supplier’s offer prices a FAT and a SAT. Three teams, three sets of initials, one system, and nobody in the room can say what will be tested twice and what will not be tested at all.

Drawn properly, the V-model makes one promise: everything specified on the left is proven by something named on the right. When that holds, the three vocabularies describe the same evidence. When it breaks, you end up with duplicate scripts in one place and a hole in another.

One system, three dialects

Quality talks in qualification stages: design qualification (DQ), installation qualification (IQ), operational qualification (OQ), performance qualification (PQ). What each stage proves, and what it cannot, is covered in what each qualification stage proves, so we will not repeat it.

The supplier talks in acceptance tests. A factory acceptance test (FAT) runs at the supplier before shipment, a site acceptance test (SAT) on your site after delivery. EU GMP Annex 15 (2015) describes both (§3.4 to §3.7).

The IT project talks in test levels. Unit tests cover one piece of code or configuration. System integration testing (SIT) covers the assembled system and its interfaces and is run by IT with the supplier. User acceptance testing (UAT) covers the whole system, with real users, approved procedures and the target environment.

None of these replaces the others, and none of them is a regulatory term. EU GMP Annex 11 (2011), which governs computerised systems, never mentions FAT, SAT, SIT or UAT. It asks for documentation covering the relevant life-cycle steps, justified by risk (§4.1), user requirements “traceable throughout the life-cycle” (§4.4), and “evidence of appropriate test methods and test scenarios” (§4.7).

So the argument about whose words to use is beside the point. What a reviewer wants to know about any test is simpler: which requirement it verifies, who ran it, in which environment, and what happened when something failed.

The left branch: three documents, three different authors

The validation plan comes first: scope, strategy, roles, deliverables, acceptance criteria, and what will be reused from the supplier. It is approved before the work starts.

The user requirement specification (URS) is written by the people who will use the system, not by the supplier. Annex 11 §4.4 asks that it “describe the required functions of the computerised system and be based on documented risk assessment and GMP impact”. Every requirement gets an identifier, because that is what the right-hand branch points back to. Writing a URS that drives the qualification covers the rest.

The functional specification is the supplier’s answer, what the system will do for each requirement. The configuration and design specification says how: configuration values, user roles, master data, interfaces and, for anything coded, the modules themselves.

DQ is the review gate over those three, and for a configured product it is often short. Annex 11 §3.3 asks that “documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled”. That review, signed, is most of your DQ.

A working rule we use: a requirement with no identifier will not get tested, and a sentence in a specification with no requirement behind it needs someone to say who asked for it.

The bottom of the V: build, FAT, SIT

At the bottom of the V sits the work itself: order, build, configure, and the supplier’s own testing. The FAT happens here. Annex 15 §3.5 expects equipment, where applicable, to be confirmed against the URS or functional specification at the vendor site before installation, and §3.6 allows FAT tests not to be repeated on site at IQ or OQ “where appropriate and justified”. Those two words carry a lot of weight; what the supplier’s tests can prove for you sets out what the justification has to contain.

SIT belongs to the same part of the V. It is where the software meets everything it talks to: the enterprise resource planning (ERP) system that sends the order, the historian that stores the values, the instrument that returns a result. Interfaces need scripts of their own, because they fail quietly. Guidance PI 041-1 (2021) from the Pharmaceutical Inspection Co-operation Scheme (PIC/S) puts it plainly: interfaces “present a risk whereby data may be inadvertently lost, amended or transcribed incorrectly during the transfer process” (§9.4).

Run SIT before the users arrive. A UAT session that spends its first morning on a broken interface costs ten people a day, and the scripts that get dropped are always the ones at the end.

The right branch: what IQ, OQ and PQ prove for software

IQ shows the system is installed as specified: versions and patch levels, configuration baseline, interfaces, accounts, infrastructure. The Principle of Annex 11 is blunt about that last item: “The application should be validated; IT infrastructure should be qualified.” IQ is repeated in every environment that produces evidence.

OQ shows the functions work, including the ones nobody volunteers to demonstrate: access by role, audit trail entries for creation, change and deletion, calculations, alarms, printouts, error handling. Annex 11 §4.7 names the last of these, “system (process) parameter limits, data limits and error handling”.

PQ shows the system does the job in the real process, with trained users, approved procedures, representative or real data, and the whole path from the first entry to the record the site relies on.

Whoever executes a script, the executed copy carries the same four things: the tester’s name and the date, the raw evidence (screen capture, printout, data extract), the actual result next to the expected one, and a deviation record for every failed step. A column of ticks with no evidence behind it will not get through review.

UAT is not a fourth stage. In most projects it is simply the users executing OQ and PQ scripts. Say so in the validation plan, map each script to a requirement, and the argument is over. Leave it unsaid and, sooner or later, the OQ is covered by nobody.

The horizontal links are the traceability ones: the design specification is verified at IQ, the functional specification at OQ, the user requirements at PQ, and the report closes the plan. The July 2025 draft revision of Annex 11 spells it out: “Test cases should be traceable to individual requirements or specifications, e.g. by means of a requirements traceability matrix” (draft §9.5). It is still a draft; the text in force dates from January 2011. How deep each test should go is a separate question, answered in tying test depth to risk.

The risk assessment decides which scripts exist

The risk assessment is not one chapter of the plan; it runs through the whole V. Annex 11 §1 requires decisions “on the extent of validation and data integrity controls” to rest on “a justified and documented risk assessment of the computerised system”.

In practice, list the functions the system performs in your process, not the ones in the brochure. For each, ask what a failure or a misuse would do to the patient, the product or the data. The answer sets the depth of the script.

A genuine risk assessment works in both directions. Some scripts exist only because of it, and some obvious ones are justified away by it, in writing. GAMP 5 Second Edition (ISPE, July 2022) is built around that judgement: critical thinking over volume, supplier documentation used rather than duplicated, and an approach that “is not inherently linear” (what changed in the second edition).

The FDA has taken the same line for medical device manufacturers in its Computer Software Assurance guidance (final September 2025, reissued February 2026): effort and records follow the risk of each software feature.

Three environments and one gate

Tests have to be representative of production without being run in production. Hence the three environments most projects keep (development, validation and production), and hence the fact that promotion between them is the least controlled part of most projects. Annex 11 §4.7 is the hook: “Automated testing tools and test environments should have documented assessments for their adequacy.” You should be able to explain why the environment you tested in represents production.

Promote through change control, never by hand. Any change, configuration included, “should only be made in a controlled manner in accordance with a defined procedure” (Annex 11 §10). Before and after each promotion, compare the validation and production baselines. There will be differences (server names, printers, licences, interface endpoints); list them and explain why none of them can affect the result you tested.

• Test data. Synthetic or pseudonymised, never an uncontrolled copy of live records. Patient or employee data in a test system is a data protection problem (data minimisation and pseudonymisation, Articles 5(1)(c) and 32(1)(a) of the General Data Protection Regulation, GDPR) as much as a data integrity one.
• Test accounts. The generic accounts created for UAT are the ones found alive in production two years later, still shared. They also feature among the findings inspectors write most often.
• Migration. If data come from an old system, validation includes checks “that data are not altered in value and/or meaning during this migration process” (Annex 11 §4.8).

Two variants need thinking about early. On a cloud service you may not own the environments at all: the supplier does, and applies releases on its own calendar. The questions then become contractual (which sandbox you get, how much notice, what evidence you are given), and Annex 11 §3.1 requires formal agreements setting out those responsibilities. On a process control system the validation environment is often a test bench. Write down what the bench cannot prove, and keep those tests for the line.

The documentation set, and who owns each line

The table below is the file we expect to find for a configured system. Most of its value is in the last two columns.

Where this V breaks

The first place is the happy-path UAT. Ten users, one morning, every script green, and nothing tried with the wrong role, an interrupted transaction or a missing interface message. Negative tests belong in the scripts the risk assessment marks as critical.

Then the traceability matrix written last, built after execution to fit whatever tests happened to be run. It tells a reviewer nothing, and reviewers can tell. The matrix starts at the URS.

• Supplier evidence reused without assessment. A FAT report can save weeks, but only if you approved the protocol beforehand, hold the raw results, assessed the supplier’s quality system and justified the reuse in writing.
• The hot fix at go-live. The change made straight in production on the first difficult morning is the one nobody re-tested. Fix it in development, re-test, promote. If it really cannot wait, use the emergency change route and document it within the time your procedure allows.
• The frozen URS. Requirements written once and never re-read do not survive three releases. The 2025 draft asks that they be “updated and maintained throughout the lifecycle” (draft §6.4). Re-reading the URS before each release is the cheapest review in the whole project.

If a test cannot name the requirement it verifies, it is something somebody did, and it proves nothing.

References

• EudraLex Volume 4, EU GMP Annex 11 Computerised Systems (January 2011): Principle, §1, §3.1, §3.3, §4.1, §4.4, §4.7, §4.8, §10, health.ec.europa.eu
• Draft revised Annex 11, Chapter 4 and new Annex 22, consultation 7 July to 7 October 2025; §6.4 and §9.5 quoted as draft, picscheme.org
• EudraLex Volume 4, EU GMP Annex 15 Qualification and Validation (2015), §3.2 to §3.7, health.ec.europa.eu
• PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (1 July 2021), §9.4, picscheme.org
• US FDA, Computer Software Assurance for Production and Quality Management System Software (final 24 September 2025; reissued 3 February 2026), fda.gov