Skip to main content
Home / Resources / Blog / Overcoming Pitfalls and Challenges with Software Validation

Overcoming Pitfalls and Challenges with Software Validation

As a quality consultant and quality system subject matter expert in the Life Sciences Industry for over 25 years, I have worked for many pharmaceutical companies both large and small and as a consultant with many clients in the pharmaceutical, biotech, and medical device industries. These clients possess a range of experience in software validation—from those who have internal resources who are very familiar with regulatory requirements for software validation to small companies who need more support and external expertise. Regardless of expertise, validation has pitfalls and challenges and is resource intensive.

The FDA Code of Federal Regulation (CFR), and specifically 21CFR11, provides not only guidance for validation and testing, but also for other important criteria such as record protection and retention, system access limitation, operational system and authority checks, personnel qualification, system documentation, and audit trails. The regulation is very broad and can be interpreted in several ways. This may result in more validation being performed than required. To that end, Good Automated Manufacturing Practice, GAMP®, is an industry guideline that provides a risk-based approach to compliant GxP computerized systems. The current version, GAMP 5, is followed by most validation personnel in regulated industries such as pharma and biotech. GAMP 5 not only provides a rich resource of information for computer systems, electronic signatures, and software development lifecycles, but also provides a risk-based approach and guidance on all validation issues.

The lifecycle of a computer system is comprised of different subprojects within the lifecycle phase: in Concept, assessments are done, validation plans are developed, scripts are written, and governance processes are formalized. Upon release to Operation, the system is monitored, applying any changes using change control through system Retirement.

Source: GAMP 5—A Risk-Based Approach to Compliant GxP Computerized Systems.

One of the more important features of GAMP 5 that is unique to prior GAMPs versions is that it allows you to “partner” with vendors and, in turn, leverage supplier involvement. This reduces some of the validation burden on companies since they can now partner with vendors and leverage their knowledge, experience, and validation documentation.

Vendor quality practices

Relying on vendor experience can minimize the need for a client to “retest” the software core functionality. However, it is standard to audit the vendor’s procedures and software development lifecycle to ensure it meets your company’s quality standards. You will need to evaluate all their processes for quality management according to your expectations and any formal audit procedures.

Depending on the risk of the vendor, eg, how good are their quality practices, this can be done as a 1-day audit every 2 to 3 years if their practices are robust. If the vendor has less robust processes or has a homegrown system, an audit can be done yearly to make sure they are keeping up-to-date with quality practices. Qualifying vendors longer than this timeline, eg, every 5 years, should only be considered for vendors that are standardly used in the regulated industry space. In this case, the vendor audit should be referenced in your validation plan to justify why a full IQOQ was not performed. It is also important that the vendor is available in the event of an audit so that they can assist if any questions arise that would pertain to their documentation. Note, vendors should be qualified throughout the lifecycle of your system.

Vendors should be held to high quality standards and there are numerous things you should assess when auditing a vendor: what types of methodology do they use? Are standard coding terms and personnel qualifications used? How do they manage documents and procedures? What methods do they use for review and approval?

Develop an audit plan and scope of activities that outlines the documents that will be reviewed and activities that will be evaluated. The vendors should be able to deliver very robust and strict document control on software development lifecycle (SDLC) methodology, project planning, design and programming standards, configuration management, testing standards and procedures, and others. A typical audit assesses their quality system, including training programs, customer support, data center, and computing environment.

Challenge #1: Internal versus SaaS-based validations

Internal validation requires full functional testing for infrastructure and server qualification, ie, installation qualification, operational qualification, and performance qualification (IQ, OQ, and PQ) since software is installed on an internal server.

A vendor that is doing installs and system testing will have their own standard operating procedures (SOPs) and have done a full functional OQ. Once you have audited them and are confident that they have implemented robust processes on software development lifecycles and functional specifications, the amount of validation you need to perform is much less. This saves resources and cost.

Sometimes it’s unclear who is responsible for “Software as a Service” (SaaS) validation. All validation is the client’s—not the vendor’s—responsibility for computer systems. Even if the client depends on the vendor’s validation document, the client is responsible for maintaining the system in a validated state moving forward. Any system structure changes need to go through impact assessment and change control. At minimum, SOPs will need to be written for the system administration SOP to show what does and does not require change control. Ensuring a robust qualified system will result in fewer interruptions in day-to-day business operations.

Challenge #2: Validation poses a burden on internal resources

Another common challenge expressed in the industry is that validation can be a large burden on internal resources. To overcome this challenge, ensure that validation, which is time-consuming, is a shared responsibility within the organization and not the sole responsibility of IT. Validation should be a partnership with the vendor (drives the quality of the system), QA (reviews and approves the documentation), IT (document review, approval, and PC user set up), the business owner (document author), and the system administrator. Collectively, the team has a clear understanding of the intended business use. In short, minimize the burden by (1) leveraging your vendor’s expertise, (2) purchasing validation packages, or (3) bringing in an industry-experienced validation consultant.

Challenge #3: Validation takes a long time

This can be especially daunting when implementing home-grown systems that require installation and qualification of a data center, backup and restore processes, servers, and application installations. Taking a risk-based approach to validation will help reduce the amount of testing and resources needed. Examine the safety of high risk system components, eg, risk to patient data. Software used for analysis of patient data, and used in a dossier to a Regulated Agency regardless of country, requires robust testing to ensure you are consistently getting accurate input, output, and reporting.

Challenge #4: Validation is expensive

Validation can be expensive. But it should be a one-time cost at system implementation to contract vendor and/or consultants to assist; maintaining a validated state can be done with internal resources. To minimize validation expenses, ensure that system governance procedures have been correctly established. Although time-consuming, in the long run, partnering with your vendor and/or consultants is the best way to keep validation costs in check. GAMP 5 explains how to use the risk-based approach to ensure you are qualifying everything to the extent it is needed, and how to avoid doing excessive validation. User requirements should be verified by the regulated company by performing acceptance tests, and other required tests can be identified based on risk, complexity, and novelty.

So how much validation is enough? It is always good practice to keep current on industry standards based on the regulatory requirements. Most companies take a moderate approach to validation and do enough to satisfy internal quality requirements, eg, testing the high-risk features of the system, intended business use, workflows, e-signature and compliance requirements, and eliminating full OQ functionality testing if the vendor has robust quality systems in place.

Best practice guidelines for system governance and release

One misconception by companies is that once validation is complete, they believe they are done. However, validation is an ongoing process which requires system governance, ie, moving forward, to determine how the system will be regulated. Proper procedures need to be in place for change control, system administration, and maintenance, and managing system releases needs to be monitored to ensure the validation is maintained. In addition, items associated with vendors, eg, frequency of new functionality releases, can impact your business and should be accounted for when writing the system governance. A best practice for system releases is to be aware of vendor release practices prior to buying the system—minimally, 30- to 60-day notification is standard for upcoming releases. A vendor “how to” product release guide should be reviewed by users, QA, and IT, followed by an assessment of impact on the business: will the release require training, does it change the user interface, etc.

Regulatory agency focus on data integrity and protection

Finally, be aware of FDA and EU requirements on data integrity and protection. The FDA is focusing on data integrity and the concern with shared login accounts. Internal users should be trained on current and upcoming quality requirements, especially as it pertains to data integrity, to ensure they are following the standard practices the FDA (21CFR11) requires for documentation control to meet CGMPs. The EU introduced General Data Protection Regulation (GDPR) that outlines steps needed to ensure data protection; vendors need to protect data that’s within the system if that system is in a SaaS.

Validating Phoenix software: Phoenix Technology Services and Validation Suite for Phoenix WinNonlin

Phoenix Technology Services provides validation services for Phoenix WinNonlin® and the Phoenix Knowledgebase System (PKS), leveraging Certara’s in-house validation experts for IQ and OQ documentation. We can eliminate the burden on a client’s internal project team to meet regulatory compliance requirements for computer system validation. Phoenix WinNonlin Validation Suite, integrated into Phoenix 8.1, provides software validation in under 30 minutes with locked PDF reports containing links to results. Updated validation template documents are aligned with the latest regulatory guidance computer system validation such as ICH E6 Good Clinical Practice (GCP) R2 and can be readily modified to fit individual user/organizational policies and procedures.


European Commission. (2018, January 9). Data Protection. Rules for the protection of personal data inside and outside the EU. Retrieved from

International Society for Pharmaceutical Engineering. (2008, February). GAMP 5 Guide: A Risk-based Approach to Compliant GxP Computerized Systems. Retrieved from

International Society for Pharmaceutical Engineering. (2018, June 13). GAMP 5: Past, present and future. [Blog post]. Retrieved from

QACV Consulting. (2017). Website. Retrieved from

US Department of Health and Human Services, Food and Drug Administration. (2003, August). Guidance for Industry Part 11, Electronic Records; Electronic Signatures—Scope and Application. Retrieved from

Want to learn more on how to make validation easier? Be sure to check out this recent webinar.

About the author

By: Noreen Muscat

Powered by GlobalLink OneLink Software