Summary

During recent MES/IT vendor demos for a “paper‑less” pharmaceutical factory, two things stood out:

1. No one mapped or discussed data‑flow and data‑risk end‑to‑end, despite years of regulatory focus on data governance.

2. Everyone leaned on the GAMP‑5 V‑model and promised layers of testing, yet struggled to explain what new assurance IQ/OQ actually adds beyond what was already tested earlier. Meanwhile, current guidance encourages risk‑based, outcome‑focused assurance that leverages supplier activities instead of duplicating them.

It’s time to replace rote, paper‑heavy rituals with critical thinking about data integrity, intended use, and risk—and to align validation with what standards actually say, not with what we’ve always done.

The Demos That Sparked This Post

I’ve sat through several polished presentations from serious global MES/IT suppliers. The teams were professional and well‑intentioned. Yet two gaps were hard to ignore:

• Gap #1: Data as an afterthought. No one brought a clear view of how data (and data risk) flows across systems—where it’s created, transformed, stored, secured, and reviewed; which controls apply; and where a failure would threaten product quality, patient safety, or release decisions. That blind spot is surprising given the long‑running regulatory emphasis on data integrity and governance across GxP environments (discussed since mid‑2010s and finalized in PI 041‑1 in 2021 along with other entities).

• Gap #2: A V‑model on repeat. Slide after slide reiterated GAMP‑5 deliverables and a V‑model story, plus lots of pre‑IQ/OQ testing. But when I asked what’s actually different during IQ/OQ—what assurance is added that wasn’t already demonstrated earlier—the answers drifted toward “because Annex 11/15; 21CFR11” and customer expectations, not toward risk‑based intent or measurable outcomes.

What the Standards Really Emphasize

1) Data governance and integrity are not optional “extras”

PIC/S PI 041‑1 frames data management and integrity as a core responsibility for manufacturers and distributors, requiring firms to assess vulnerabilities and implement appropriate governance—exactly the kind of end‑to‑end view missing from many demos.

Implication: Any “paperless” program should start with a data‑flow and risk map (where data originates, who can change it, how it’s protected, and how it’s consumed for decisions), plus controls and monitoring tied to that map.

2) GAMP‑5 (Second Edition) is about critical thinking, not box‑ticking

The Second Edition keeps the familiar framework but explicitly elevates critical thinking, proportionate effort, and the role of suppliers, and it supports iterative (Agile) as well as linear lifecycles—the V‑model is a tool, not a straightjacket.

Implication: Leverage supplier testing and evidence where appropriate; focus your own testing on intended use and risk to patient/product/data, not on recreating what’s already been proven.

3) Annex 11 and Annex 15 set principles, not paperwork quotas

Annex 11 (Computerised Systems) and Annex 15 (Qualification & Validation) define expectations for control, fitness for intended use, and a lifecycle approach. They do not mandate redundant re‑testing when risk is low and supplier assurance is sound; they point toward science‑ and risk‑based qualification and validation.

4) FDA’s Computer Software Assurance (CSA) pushes outcome‑focused evidence

FDA’s CSA guidance (now finalized for production and quality system software) encourages risk‑based assurance, leveraging unscripted/exploratory testing where it adds value, and relying on digital evidence over paper-heavy artifacts—freeing teams to put effort where risk is highest.

Why the V‑Model Keeps Getting Misapplied

The V‑model is a communication device—a way to show traceability from requirements to testing. Problems arise when it’s treated as a checklist to be repeated at each stage:

• Over‑specification and under‑thinking.

  Teams output piles of documents but struggle to answer simple questions like “Which failure here could release bad product?”

• Duplicative IQ/OQ.

  If a supplier has robust development controls and verification, re‑executing functionally identical tests during IQ/OQ rarely changes the risk picture.

• Perverse incentives.

  Auditors like seeing familiar forms; buyers ask suppliers to “do it how we’ve always done.”

  Cost goes up, quality doesn’t.

GAMP‑5 Second Edition and CSA both encourage a different conversation: What evidence—supplier or user—best demonstrates fitness for intended use, given the risk?

A Practical Playbook: How to Run Your Next MES/IT Evaluation

1) Start with a Data‑Flow & Risk Map

• Identify

  where data is generated, transformed, stored, reviewed, and released (including interfaces, historians, eDHR/eBR, and analytics).

• Classify data by impact (patient/product/release) and map controls (access, audit trails, reconciliation, exception handling, backup/restore, retention).

• Tie risks and controls back to recognized data‑integrity expectations (e.g., governance, security, traceability).

2) Ask Suppliers for Assurance by Design

• Development lifecycle, quality system, and testing strategy (including automated tests and continuous integration).

• Evidence of requirements traceability and risk‑based testing; where do they perform stress, boundary, security, and failure‑mode tests?

• How their evidence can be leveraged in your validation—per proportional risk principle of GMP and GAMP‑5’s emphasis on suppliers and proportionate effort.

3) Right‑size Your IQ/OQ/PQ

• Define what’s unique to your intended use, configuration, and integrations—that’s what you test.

• Where supplier evidence is robust, reuse it and add targeted, outcome‑focused user testing (exploratory/unscripted where it makes sense).

• Keep Annex 11/15 in view, but let risk drive the level of additional testing and documentation, not tradition.

4) Measure What Matters

• Define assurance outcomes up front: e.g., “No untracked paths to release,” “All critical data changes auditable,” “Alarm/exception handling proves reliable under load,” “Restore times meet X.”

• Instrument systems to capture digital evidence (logs, audit trails, automated test outputs, monitoring)—evidence that inspectors and QA can evaluate quickly.

A Short Checklist for Vendor Demos

Use these questions to avoid ritual and get to substance:

1. Show me the data‑flow.

   Where can data be lost, corrupted, or altered without trace? What are the controls? How are audit trails reviewed? [simple diagrams should be utilized]

2. What earlier testing can we leverage?

   Which tests demonstrate fitness for our intended use, and which would be duplicative?

3. What changes between pre‑IQ/OQ and IQ/OQ?

   Which risks are newly addressed in IQ/OQ, and why? Tie each to a risk statement from our map.

4. How do you support CSA‑style evidence?

   What unscripted/exploratory testing and digital evidence are available?

5. How does your approach align to Annex 11/15 expectations without over‑processing?

   Give specific examples.

What we should focus on

Many inspection expectations were shaped in an era when paper evidence was the only evidence. Today’s guidance increasingly supports risk‑based, outcome‑focused assurance and the use of supplier evidence, with the ongoing revision of Annex 11 further underscoring a modern PQS lens for computerized systems. Let’s align on what proves control, not on how heavy the binder is.

Conclusion

If we want real quality from “paperless” manufacturing, we need to stop Pavlov‑ing and start thinking:

• Lead with data‑risk and data‑flow

• Let intended use and risk determine the right evidence.

• Leverage supplier assurance where it’s strong.

• Use CSA‑style testing and digital records to prove control efficiently.

Understanding is the foundation of GMP. No understanding, no GMP.