Computer System Validation Software: Why Does Every GxP Change Still Cost You Three Weeks of Screenshots?

Why validation costs three weeks that produce nothing

A quality systems lead is closing out a change to a laboratory information system. The change was a configuration update that took an engineer forty minutes. The validation package is a user requirement specification in Word, a risk assessment in Excel, a traceability matrix built by hand from both, eleven test scripts in a template with the version number in the file name, executed by a tester who pasted 94 screenshots into the documents, printed them, initialled and dated each page, and walked the folder to three approvers. Two of those approvers were travelling. The package closed nineteen days after the engineer finished.

Nothing in that story was wasted because of laziness. Every step exists because 21 CFR Part 11 and EU Annex 11 demand evidence and controlled signatures, and because an inspector will ask to see the link from a requirement to the test that proves it. The waste is in the medium. Requirements live in documents, so traceability has to be rebuilt by a person. Evidence lives in screenshots, so it cannot be generated. Approvals live in signatures on paper, so they move at the speed of someone's calendar.

Across quality systems projects we have delivered, the recurring numbers are two to four weeks of elapsed time per validated change regardless of the size of the change, and a documented traceability matrix that is correct on the day it is signed and stale within a quarter. The commercial argument is simple. Validation effort is a tax on every GxP system you own, it scales with the number of systems and their release frequency, and both of those numbers only go up.

Problem 1: the requirement is the unit of work, and you keep it in a document

Everything in validation hangs off requirements. Risk is assessed per requirement. Tests prove requirements. Change impact is measured in affected requirements. Periodic review asks whether requirements still hold. When requirements live in a Word file, none of those relationships exist in a form anything can query, so each one is reconstructed by hand into a matrix that is a snapshot rather than a system.

ValGenesis and Kneat Gx both solve this properly and they are good products. Veeva Vault Validation Management does it well if you are already committed to Vault, and MasterControl's module makes sense inside a MasterControl estate. The honest limitation of all of them is that they encode a validation approach, and your quality manual encodes yours. Risk classification schemes, test evidence expectations, the relationship between validation and your change control and deviation processes, and what a periodic review must contain are defined by your organisation and audited against your own procedures. Where a commercial tool's model and your procedure disagree, one of them changes, and it will not be the tool.

What a custom build does: make the requirement a first class record with a stable identifier, a version history, a GxP impact classification, linked risks, linked test cases, and links to the change requests that created or altered it. Traceability stops being a document you produce and becomes a query you run. When someone asks which tests cover a requirement, or which requirements a proposed change touches, the answer takes seconds and is always current.

Problem 2: evidence capture is a person taking screenshots

Executed test evidence is the bulk of a validation package and almost all of it is a human doing something a computer could do. A tester performs a step, captures the screen, pastes it into a document, annotates it, and signs. For scripted functional testing of a configured system, that is the process, and for a long time there was no alternative.

There is one now, and it is the single largest cost reduction available in this category. The FDA's computer software assurance thinking, set out in draft guidance published in 2022 and reinforced by the second edition of GAMP 5, points effort toward critical thinking, unscripted and exploratory testing for lower risk functions, and automated testing where automation is credible. What it asks in return is that you can justify the approach per function based on risk and patient impact.

What a custom build does: capture evidence from the test execution itself. An automated test run against the system under test produces structured results, screenshots, timestamps, environment identity, and the exact build tested, and posts them against the test case as evidence with the same integrity controls a human execution would carry. Manual execution remains available and should, because some steps genuinely need a person, but it stops being the default for everything. In our experience this is where a package that took nineteen days starts closing in three, and the three are review rather than transcription.

Problem 3: risk assessment is theatre unless it changes the test effort

Most organisations perform a risk assessment, file it, and then test everything to the same depth anyway. That is the worst of both worlds. You pay for the assessment and you pay for the testing it was supposed to reduce.

What a custom build does: bind test depth to the risk score mechanically. A high risk function with patient impact requires scripted testing with full evidence and independent review. A low risk function supported by a vendor's own testing and a supplier assessment requires a documented rationale and a lighter check. The system enforces the rule your quality manual states, so the assessment produces an actual test plan rather than a filed document, and an inspector can see the logic rather than take your word for it. The rules belong in configuration your quality organisation controls, not in code we write, because your classification scheme will change after your next audit.

Problem 4: approvals cross departments and stall

A validation package needs signatures from quality, from the system owner, from IT, and sometimes from a process owner in operations. Under Part 11 those signatures need identity, meaning, timestamp, and a link to the record that cannot be broken. On paper that is a folder walking a building. In email it is not compliant at all, whatever anyone tells you.

What a custom build does: electronic signatures with re authentication at the point of signing, a signature manifest that shows name, role, meaning, and time, and a record that cannot be altered after signature without a new version and a documented reason. Routing is parallel where your procedure allows it, with reminders and delegation for planned absence, because the most common cause of a stalled package is one approver on annual leave with no delegate configured.

Problem 5: the validated state decays between projects

Validation is treated as a project and lived as a condition. Between projects, a cloud vendor pushes a release you did not schedule, an operating system gets patched, an integration partner changes an interface, and a user is granted a role nobody assessed. Periodic review is supposed to catch this, and in most organisations it is an annual document exercise performed from memory.

What a custom build does: hold a system inventory where each system carries its GxP classification, its current validated version, its supplier assessment date, its periodic review date, its open deviations, and its configured integrations. Where the system can be queried, the platform checks the deployed version against the validated version and raises a discrepancy when they diverge, which is how you find out that a supplier updated your software in a maintenance window rather than finding out during an inspection. Periodic review then becomes a review of facts the system already holds instead of an interview.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering requirements with versioning and traceability, risk assessment driving test depth, test execution with electronic evidence, and Part 11 compliant approvals runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding the system inventory with validated state monitoring, periodic review, links to change control and deviation processes, supplier assessment records, and automated evidence ingestion from CI pipelines runs $200,000 to $450,000 phased over 8 to 14 months.

• Whether the platform itself must be validated, which it must if it holds GxP records. Plan its own validation package from the start and expect it to add real weeks.
• Number of quality processes you connect. Change control, deviation, CAPA, and training each have their own owner and their own system, and each integration is a negotiation before it is code.
• Whether you want automated evidence capture. This pays back fastest but requires your systems to be testable, which for older client server applications may not be true.
• Number of sites, because a global quality manual with site level procedures means configurable rules rather than one hard coded flow.

Build versus buy, and when buying is right

Buy if your validation volume is low, meaning a handful of systems that change once or twice a year. ValGenesis and Kneat Gx are mature, they are used by inspected companies, and buying gets you running next quarter for less than a build. Buy if you have no internal appetite to own a validated application, because this system will itself be inspected and someone has to maintain it.

Build when two or more of these are true. You have a large estate of internal applications that release on a modern cadence, and a document driven validation tool is now the reason software takes a quarter to ship. Your risk classification and evidence expectations differ meaningfully from what commercial tools model, and you have been forced to change your procedure to fit a product. You want validation evidence generated by your test automation rather than pasted by a tester, which is the case a commercial tool serves least well today. You run several sites with genuinely different procedures. Or your validation cost per change has become a line item leadership asks about.

How to choose a developer for validation software

Ask them what ALCOA plus means for the audit trail design before you sign anything. A developer who has worked in GxP will talk about attributable and contemporaneous records, about why a soft delete is still a deletion, and about time synchronisation across services. A developer who proposes an updated at column has not been inspected and will learn on your budget.

Ask how the system validates itself. If they have no answer, they do not understand that this application will be inspected as a GxP system, and the retrofit will cost more than the build.

Ask how your risk classification scheme gets changed. If altering a risk to test depth rule requires a code release and therefore a validated change to the validation system, they have designed a trap. Those rules belong in controlled configuration.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. A system that holds the evidence of your validated state must be recoverable without a vendor's cooperation, because you will be asked to produce that evidence for years after any contract ends.