Computerized System Validation: 3 Pages Inspectors Read
An inspector does not read a validation package from page one. He opens three places and works from there: the requirements traceability matrix, the raw execution records for high-risk functions such as permissions, audit trail, electronic signature and backup and restore, and the deviation list together with its conclusion statement. If those three hold up, the remaining pages rarely matter at all.
The fifteen minutes that decide an inspection
A quality assurance team once wheeled in a bound LIMS validation package for an inspection. URS, FS, DS, installation qualification, operational qualification, performance qualification, a traceability matrix, training records. More than 400 pages, every line marked Pass.
The inspector never started at the beginning. He did three things instead.
First he opened the traceability matrix, picked a requirement more or less at random (“the system shall prevent modification of approved data”) and asked which test script covered it, and where the executed record was.
Then he asked for a live demonstration. Log in as a QC operator, try to change a reviewed test result, then pull the audit trail for that record.
Then he asked how many deviations had been raised during validation, and how many were still open.
Fifteen minutes later the conclusion was written. The script linked to that requirement tested “a reason must be entered after a modification”, not “modification is prevented”. The operator changed the reviewed result successfully, right there in front of him. Three deviations had been closed as “low risk, accepted”, and not one of them had a risk assessment behind it.
Four hundred pages. None of them demonstrated that the system could be trusted.
| Inspection move | What was asked | What came back |
| Traceability spot check | Which script covers “modification of approved data is prevented”? | A script that tested reason-for-change entry, not the prevention itself |
| Live demonstration | Change a reviewed result as a QC operator, then show the audit trail | The change succeeded |
| Deviation question | How many test deviations, and how many remain open? | Three closed as low risk with no assessment |
Document thickness is not evidence strength
Validation produces evidence. Reports are just the container it arrives in.
The second edition of GAMP 5 puts critical thinking at the centre of the discipline, and the reasoning is straightforward enough. Nobody sets out to exercise every function a system happens to have. The point is to produce evidence, proportionate to risk, that the system does what it claims under its intended use, and carries on doing it.
Hold a typical GMP validation report against that standard and roughly 70 pages in every 100 turn out to be vendor template text carried over unchanged, screenshots stacked one after another, and tests of functions where a failure would carry no GxP consequence at all. Inspectors skip that material, and not because they are lazy. It carries no probative weight.
The V-model sequence of URS, FS, DS and IQ OQ PQ still has its place. It just is not where the proof lives.
Three pages decide the outcome.
The three pages that decide the outcome of computerized system validation
| Page | Artifact | Question it answers | Most common finding |
| 1 | Risk-based requirements traceability matrix | Is every GxP-critical requirement covered by a test of matching depth? | Coverage is claimed, but the linked script tests something else |
| 2 | Raw execution records for high-risk functions | Did the test actually run, on that system, by that person, on that date? | Reused screenshots, dates out of sequence, no negative testing |
| 3 | Deviation list plus conclusion statement | What went wrong, and on what basis was the system released anyway? | “Low risk, accepted” with no assessment behind it |
Page 1: the risk-based requirements traceability matrix
The requirements traceability matrix (RTM) is the inspector’s navigation chart, and it is the fastest read available on how mature your validation practice really is.
A defensible matrix links four columns: requirement ID, then GxP impact together with a risk level, then test script ID, then execution result with any deviation number.
| Column | Content | Why it is there |
| Requirement ID | Stable identifier, usually from the URS | Lets anyone jump from a claim to its evidence |
| GxP impact and risk level | Patient safety, product quality, data integrity | Sets how deep the test has to be |
| Test script ID | The specific executed script | Proves the test exists and was run |
| Result and deviation number | Pass or Fail, plus any deviation raised | Makes failure traceable to its closure |
Three judgments get made on this page.
Does the matrix cover every GxP-critical requirement?
The list of functions that matter for GxP compliance is short and stable: audit trail, access control and permissions, electronic signature, data integrity controls, backup and restore, and any calculation or decision logic the system applies to regulated data. Leave a hole anywhere in that list and the inspector will find it within two minutes, because those are the rows he reads first.
Is the test depth proportionate to the risk?
The defect people get cited for is rarely a missing test. It is a test that exists but is nowhere near deep enough for the risk it claims to cover. A requirement rated high because it protects data integrity, evidenced by a script that says “open screen X and confirm field Y is present”, is a mismatch. High risk calls for realistic conditions, negative cases and retained raw output. Not a glance at the screen.
Does every failure lead somewhere?
Each validation deviation that comes out of a Fail row has to continue into an assessment, a fix, and a repeat of the affected test. A matrix with no Fail rows and no deviation references reads as something produced after the fact, rather than during execution.
That is the whole point of risk-based validation. The matrix is not a checklist to be completed. It is the argument that your testing was aimed at the things that could actually hurt a patient, a batch, or a record.
Page 2: raw test evidence for the high-risk functions
Once the matrix points at a script, the inspector asks for the executed record. Five categories come up almost every time.
Permissions: test what the system refuses
Most teams test that a user with the right permission can perform an action, which is the easy half. The half that matters is the refusal: a user without the role gets blocked, an attempt at escalation gets denied, and the denial lands in the audit trail. A permission matrix tested only in the positive direction has not been tested at all.
Audit trail: five elements, plus whether it can be switched off
Every change has to capture the value before, the value after, who made it, when, and why. Those five elements are the working expression of ALCOA+: attributable, legible, contemporaneous, original and accurate. On top of that, the test has to establish that the audit trail cannot be disabled by a normal user, that any configuration change to it is itself recorded, and that entries cannot be edited or deleted afterwards.
Electronic signature: is the signature separable from the record?
The signature has to be bound to the record so that it cannot be moved or applied elsewhere. The meaning of the signature, whether reviewed, verified or approved, has to be displayed alongside it. Re-authentication should happen at the moment of signing instead of relying on a session that stays open.
Backup and restore: a log is not a restore
Backup and recovery testing is where otherwise solid packages fall apart. A backup job log proves a file was written, and says nothing about whether that file can be read back into a working system with its integrity intact. What inspectors want to see is a restore into a recovery or test environment, with record counts and data checks confirming completeness, repeated at a defined interval. Backup without restore stays one of the most commonly cited serious findings in GxP inspections.
Boundary and failure conditions
Power loss during a save, network interruption mid-transaction, two users editing the same record at once, out-of-range input. All of them need to leave the data consistent. These tests take real effort to set up, which is precisely why they are the ones most often quietly left out.
What the inspector looks at here is almost mundane. Executor signature, date, raw output attached. Then he checks the handwriting, the sequence of dates, and the system clock visible in the screenshots. Records reconstructed after the fact almost always break on one of those three.
Page 3: deviations, residual defects, and the conclusion statement
Most teams treat this as an appendix. It is the page that tells an inspector the most about your quality culture.
What the deviation list has to answer
What went wrong during validation, what the root cause was, what was done about it, and on what basis the system can be used with anything still outstanding.
What an open item has to carry
Three things. A documented risk assessment. An interim compensating control at SOP level, not a promise to be careful. And a closure date with a named owner. Writing “low risk, acceptable” with nothing behind it is not a disposition, it is an admission that quality decisions on the site are not under control.
What the conclusion statement has to fix in writing
System name and version, the validated configuration, the environment it was tested in, the functions covered by testing, and the intended scope of use. Anything outside that description sits outside the validated state. A statement that simply declares the system validated, with no boundaries recorded, gives you nothing to defend later.
The uncomfortable part: a clean report can be the worst signal
A matrix where every row reads Pass and no deviation was ever raised does not look like excellence. It looks like a document produced to close a project.
Real systems fail tests. Configuration gaps, permission errors, calculation differences and interface problems all show up as soon as scripts are run honestly against a configured system. A mature package usually carries a handful of deviations, each with an assessment behind it, most closed before release, and the remainder released with a compensating control and a date attached.
Put plainly: a Fail with a proper assessment is defensible. A Pass with nothing underneath it is not.
Five changes to make before the next inspection
- Move the effort from writing to proving. Cut the template text and spend the recovered hours on negative testing, exception testing and real restore drills.
- Rebuild the matrix around risk rather than around the document set. Where a requirement has no GxP consequence, say so in writing and move on. Where it does, prove it properly.
- Fund the tests nobody enjoys. Concurrency, interruption, out-of-range input and restore-into-environment are where systems actually break.
- Treat release as the starting line. Change control, periodic review and supplier audit are what maintain a validated state over time. A system running for three years with no periodic review has quietly lost that state, whatever the original package contained.
- Make sure the person signing understands the stack. If your QA reviewer cannot say whether data can be modified at database level, or how operating system permissions interact with application roles, the signature is a formality. In a digital environment, a quality professional who cannot read the technology cannot carry that signature.
Limitations
This is written for GxP-regulated computerized systems in pharmaceutical and biotech quality environments, and it reflects common inspection practice rather than any single regulation. Obligations differ by market: US sites work under 21 CFR Part 11, EU sites under Annex 11, and local guidance layers its own expectations on top.
The proportion of low-value pages quoted above is a field observation, not a standard, and your own packages may look very different. Risk ratings depend entirely on the intended use of your system, so there is no universal mapping from function to risk level that can be copied across sites. Inspectors vary too, and a good one follows the evidence wherever it leads rather than working through a fixed checklist.
Bottom line
An inspection of your validation package is not an audit of your documents. It is a test of whether you know where this system can go wrong, and what you did about it.
FAQ
What is a requirements traceability matrix in GxP validation?
A requirements traceability matrix, or RTM, is the table that connects each user requirement for a regulated system to the test that proves it works, the risk it carries, and the result of that test. In practice it carries four linked columns: requirement ID, GxP impact with a risk rating, test script ID, and the execution result with any deviation number raised against it.
How many deviations are acceptable during a validation project?
There is no fixed number, and the count matters far less than the handling. A project that raised several deviations, assessed each one, closed most of them, and documented interim controls for the rest reads as a real execution. A project that raised none reads as though the testing never actually ran against the configured system.
Why is an all-Pass validation report treated as a warning sign?
Real systems fail tests. Configuration gaps, permission errors and calculation differences appear whenever scripts are run honestly against a live configuration. A package where every single row reads Pass and no deviation was raised suggests the documents were written to close a project, so inspectors usually go straight to the raw evidence next.
What should an audit trail test actually verify?
It should confirm that five elements are captured on every change: the value before, the value after, who made the change, the timestamp, and the reason. It should also confirm that the audit trail cannot be disabled by a normal user, that any configuration change to it is itself recorded, and that entries cannot be edited or deleted afterwards.
Is a backup log sufficient evidence for backup and recovery?
No. A log shows that a backup job finished. It says nothing about whether the data can be restored into a working system with its integrity intact. The evidence inspectors expect is a restore performed into a recovery or test environment, with record counts and data checks confirming completeness, repeated on a defined schedule.
What is negative testing in computerized system validation?
Negative testing checks that the system refuses what it should refuse. A user without approval rights tries to approve a result and is blocked. A reviewer attempts to edit a signed record and the action fails. The refusal is logged. Teams routinely test only the positive path, which leaves the control itself entirely unproven.
What belongs in a validation conclusion statement?
It should state the system name and version, the validated configuration, the environment it was tested in, the functions covered by testing, and the intended scope of use. Use outside that description falls outside the validated state. A statement that just says the system is validated, with no boundaries recorded, gives you nothing to defend later on.
How often should a validated system be reviewed?
Periodic review commonly runs annually, or on a risk-based cycle where higher risk systems are reviewed more often. The review covers deviations, changes, incidents and backup and restore results since the previous one. A system running for three years without any review has effectively lost its validated state, whatever the original package contained.
Does GAMP 5 require testing every function of a system?
No. The second edition places critical thinking at the centre and asks for evidence proportionate to risk. Functions with no GxP impact can be covered by a light confirmation, or excluded with a written rationale. Functions that protect data integrity or product quality need depth, negative cases, and retained raw evidence.
Who should sign off a validation report?
The system owner and a quality assurance representative who understands what was actually tested. A signature from someone who cannot say whether data can be changed at database level, or how operating system permissions interact with application roles, is a formality rather than a review, and inspectors test for exactly that.
