Concluding Validation 4.0 with Computer Software Assurance (CSA) and Annex 11 Framework

Based on a detailed review of the final CSA guidance from the US FDA and “Draft Guidelines: Revised Annex 11 – Computerized Systems” from the EMA, it’s clear that five of the seven identified key pillars have been featured prominently—they are points number two to number six in the table below:

The author has taken a detailed look at these five items in relation to what was originally summarized as part of Validation 4.0 model and the expectations in the recently published guidelines.

Digital Tool-Based Artifacts for System Documentation

The CSA guidance from the US FDA recommends “The use of tools supporting software development and system life cycle activities (e.g., bug, anomaly tracking, requirement traceability tools) for the assurance of software used in production or as part of the quality system whenever possible.” Most of these were part of the draft guidance with minor additions like requirement traceability tool.

The EMA’s draft revised Annex 11 guidelines mention, ‘“The use of effective tools to capture and hold requirements and facilitate traceability is encouraged.” And with the clear focus of ensuring data integrity in documentation as part of the EMA’s “Draft Guidelines: Revised Chapter 4 – Documentation,”5 use of digital tools has become more important.

The article1 had already highlighted Validation 4.0 goals to include encouraging use of digital documentation and metadata, minimization validation for software tools, and avoiding redundancies in tool usage. It had also highlighted that “prospective data integrity is a key feature of Pharma 4.0™, and usage of software tools and digital documentation ensures data integrity for validation documentation is foolproof and detailed.”

Most pharrma companies are in different phases of adoption on these and may have had apprehensions on moving away from the legacy approach. Now, with the new guidance also pointing in similar direction, its high time industry accelerates adoption of these digital tools.

Critical Thinking-based Risk Approach for Assurance Activities and Optimizing Test Scripting Rigor

The two separate points on risk approach and scripting rigor are being discussed together as they are very closely interlinked.

With respect to risk-based approach for assurance activities, appropriate risk identification and analysis for assurance activities was already part of the US FDA’s draft CSA guidance. Annex 11 from the EMA also has new additional sections on the same lines for risk identification, analysis and taking appropriate mitigation steps with process and system re-design.

With respect to validation and test scripted rigor, the final CSA guidance from the US FDA mentions, “For high process risk software features, functions, and operations, manufacturers may choose to consider more rigor such as the use of scripted testing or a hybrid approach of scripted testing and unscripted testing, scaled as appropriate, when determining their assurance activities.” This is slightly different from the US FDA’s draft guidance in that earlier there was only mention of use of different forms of scripted testing for high-risk items. The possibility of using unscripted testing for high-risk software features, functions, and operations is a welcome change.

Annex 11 only loosely mentions the need for scaling validation activities based on intended use and risks. Within the validation and qualification, the guidance says, “Test scripts should be described in sufficient detail to ensure a correct and repeatable conduct of test steps and prerequisites,” which is basically asking for a robust scripted testing approach.

This is an important difference between the approaches recommended by final CSA guidance and the Annex 11 guidance. This dichotomy is already hinted in the article1 which had highlighted a detailed model for risk-based analysis and has use cases for unscripted testing for high process risk areas identified with downgrade based on IT risk. At the same time, it highlighted a risk that there would be a temptation to downgrade a custom development (i.e., items with high IT risk) test approach to exploration or ad hoc testing. It has highlighted the practical issues with not having scripted testing for repeatability in other releases within project phase and the operations/maintenance phase as custom developments need to be verified with different scenarios.

Automated and Pragmatic Test Execution Approach

The CSA guidance says, “Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified,” which encourages a pragmatic test execution approach.

It also mentions, usage of digital technology to support automated testing, and electronic capture of work performed as objective evidence, reducing the need for manual or paper-based documentation. One of the best options for answering the scripted vs unscripted testing debate is answered in the final CSA guidance1 that “it may be more effective and efficient to develop scripted testing and automate it for not high process risk features, functions, and operations.”

The article [1] already highlighted that automated test execution is the best option to minimize manual overhead and is suitable for simple and integrated software suites that require multiple iterations. Pragmatic solutions were also discussed, but pragmatism is very subjective, and a risk-based professional judgment should be applied as per specific scenarios.

Integrating Efforts with Cybersecurity and Other Regulatory Units

Cybersecurity is one point that was not obvious in the draft version of CSA and earlier version of Annex 11 but features prominently in the latest copies.

In the CSA guidance, within Chapter 5 for additional considerations for assurance activities, it’s enumerated that, “Additional process controls, including activities to reduce cybersecurity exposure, have been incorporated throughout production.” Similarly, as part of vendor assessment there is also ask for “review of vendor’s cybersecurity practices and documentation (e.g., security risk assessments, threat modeling, security design reviews, software bill of materials (SBOM), and testing) as well as data integrity capabilities (including securing data at rest and in transit)”. It also refers to cybersecurity in medical devices guidance4 as a guiding principle.

In the Annex 11 guidance, there is a dedicated chapter (15) on security that starts with key ask of maintaining an effective ISMS and key cybersecurity concepts of firewall, penetration testing and encryption.

The article1 had already highlighted the importance of cybersecurity as a key enabler for Validation 4.0. It highlighted the potential for synergy between an information security management unit and quality assurance compliance unit across multiple scenarios including audit trails, security, data exchange, infrastructure.

Below provides a short note on two items in Validation 4.0 model, i.e., point number 1 and 7 that don’t have a prominent feature in either of the two guidances.

Process and Data Flow as Foundation for Validation Activities does not feature in CSA guidance but has a short mention within Draft Revised Annex 11. It is part of the system requirements chapter, where it says, “requirements should include process maps and data flow diagrams, and use cases may be applied.”

Continuous Control and Cognitive Compliance

Though nothing specific on these lines have been provided in either guidance with respect to the use of AI tools for supporting validation, there has been great emphasis on actual validation of AI with the publication of New Annex 22 (Artificial Intelligence).6

Conclusion

Looking back, it is possible to see a shortlist of key pillars of Validation 4.0 models.

What has been more elaborated on as part of additional assurance activities in both the new guidance documents is the information leveraging vendor documentation: They answer many open questions on the boundaries for activities for a regulated company versus a vendor in different scenarios. Similarly, the increased emphasis on cybersecurity has been long overdue. The integrated revision of GMP Annex 11 and Chapter 4, along with the introduction of a dedicated Annex 22 on artificial intelligence gives a clear direction on a path forward for achieving compliance.

It would be proper to say the year 2025 provided a definitive closure for concluding compliance challenges with Validation 4.0. It would have been nicer to have the final EMA guidelines as well, but a combination of the final CSA guidance and the draft EMA guidelines provide a clear view on what regulators expect and an assurance that regulators are committed to pragmatic solutions in fostering innovation without compromising patient safety.