Validate the risk, not the binder

When I joined an automation vendor in 2006, one of my first tasks was to prepare validation documents for a pharmaceutical customer's new batch-control system. The customer's quality team sent us its template. It asked for a screenshot of every screen, a signed test step for every field and a separate protocol for each of the forty-odd standard functions the software shared with every other system we had installed. The finished package ran to about 1,900 pages. The interface that passed batch quantities to the customer's warehouse system, the one place where a fault could have sent the wrong amount of material to a reactor, received four pages.

I have seen versions of that imbalance in every company I have worked for since, my own included. Validation of computerised systems, the documented evidence that a system does what it is intended to do and keeps doing it, is essential in a GMP environment. My argument is that it is too often measured by the volume of its documents rather than by where its testing is concentrated, and that the volume crowds out the testing that matters most.

Where the paper piles up

The habit has understandable roots. Indian manufacturers learnt validation largely through inspections and customer audits, and an observation about missing documentation is easier to prevent with more documentation than with better judgement. Contract manufacturers feel the pressure twice over, because each customer may arrive with its own expectations and templates. Consultants are often paid by the deliverable. Nobody is rewarded for a thinner package.

The regulators have not asked for this. The USFDA's 2003 guidance on the scope and application of Part 11 told companies to base their approach on a justified and documented risk assessment of each system's potential to affect product quality, safety and record integrity. Annex 11 of the EU GMP guidelines asks for risk management throughout a system's life, with the extent of validation decided by its effect on patient safety, data integrity and product quality. The industry's most widely used good-practice guide for computerised systems was revised in 2022 to press the same point, encouraging critical thinking over documentation for its own sake. The permission has existed for two decades. What has been missing is the confidence to use it.

The cost of the habit is not only money. A team that spends months scripting tests for standard functions the vendor has already tested has less time for what only the user can test: the interfaces between systems, the configuration unique to the plant, and the behaviour of the system when a network link drops in the middle of a weighing step. At Trivikaya in 2024 we found that a typical validation package for a plant system had grown to about 1,400 pages and taken seven months, while testing of interfaces between systems accounted for less than a tenth of the effort.

Critical thinking has to be written down

We changed the method during 2024 and 2025, and our head of quality, Shalaka Mhaskar, was its most demanding critic. Her concern was fair: an inspector who finds less documentation may suspect less validation. Our answer was that the reasoning must be documented even where the testing is reduced. For each system we now record which functions could affect product quality, patient safety or the integrity of a GMP record, and why. Those functions receive scripted, independently reviewed testing. Standard functions of low risk receive unscripted or exploratory testing, recorded with evidence of what was tried. Where a supplier has tested its own software well, we assess the supplier and rely on its evidence rather than repeating it.

The results have been uneven but mostly encouraging. Validation packages for new plant systems are about 58 per cent shorter, and the time from installation to release for use has fallen from about seven months to three. Testing of interfaces and failure modes now accounts for close to half the effort. In 2025 an inspection of our Kurkumbh plant by a European regulator examined two computerised systems in detail and raised no observation on either. I would not claim that as proof of the method, but it was not evidence against it. Quality also added six reviewers to its computerised-systems team, which is the part of the change people forget when they describe it as a saving.

Not every customer has followed us. Two still require their own scripted templates for systems that run their products, and we provide them. A risk-based method has to accommodate a customer's stricter expectation without abandoning its own reasoning, and I would rather maintain two standards openly than pretend one of them is the other.

What an inspector actually asks

The questions inspectors and experienced customer auditors ask about computerised systems are rarely about the number of pages. They ask what the system is used for and what would happen if it failed. They ask how a change is controlled, who can alter its configuration and whether the audit trail would show the alteration. They ask to see a record and follow it back through the system. A team that has thought hard about risk can answer those questions quickly, because it has already asked them of itself. A team that produced a thick package from a template often cannot, because the package records what was done rather than why.

I saw the difference during a customer audit at Dahej in 2025. The auditor chose the interface that sends dispensed quantities from the execution system to ERP and asked what would happen if a message were lost halfway. Under the old method the answer would have been somewhere in an appendix. Under the new one, the engineer opened the risk assessment, showed the failure mode we had identified, the test that reproduced it and the reconciliation report that now catches it every shift. The conversation took ten minutes.

For a board, this is not a technical curiosity. Validation is one of the larger recurring costs of technology in a pharmaceutical company, and it decides how quickly new systems reach the plant. Directors can ask management what share of validation effort goes to the functions of highest risk, how long a new system takes to reach release, and whether the quality function agrees with the risk assessments behind those choices. If the only answer offered is the size of the binder, the company is validating its documents rather than its systems.