Right-Sizing Computer Validation in Life Sciences

Most life sciences companies struggle to find the right balance when validating their computer and enterprise systems. They struggle to see the value of computer validation beyond meeting compliance requirements.

But what if computer validation (CSV or CSA) actually made good business sense?

Last week I presented a webinar in partnership with MWA Consulting on Right-Sizing Computer System Validation in Life Sciences and was asked some questions during the presentation. I answered most of them during the Q&A period and also in a Q&A summary provided to those who registered.

While I’d love for you to watch the webinar to get the full benefit of my years of experience and hours of prep, feel free to enjoy the following Q&A summary.

1. What is your take on leaving some software elements to be verified at the time of use versus validation? Nowadays systems can easily have 1000’s functions to validate.

I’m not a fan. We used to do a post-go live performance qualification for some functionality but that was two decades ago, and we had processes in place to address issues as they came up. With a risk-based approach, you don’t have the same level of rigor around testing for all of the functions that you intend to use in the system. If you have a good requirements specification, and a good functional risk assessment process, you can focus on the higher risk functions (based on your company’s intended use, risk tolerance, and SOPs) and leave the lower risk functions to less formal testing prior to use by end users (which makes good business sense).

2. Any insight for how best to prioritize CSV efforts for Part 11 Compliance for electronic records/electronic signatures on records/signatures required by the predicate rule while not trying to capture and validate *all* electronic records?

Generate a good requirements document and perform a functional risk assessment on each of the requirements based on established set of criteria. This criteria can be set at the SOP level or for each system / solution. Make sure the team that is assessing risk is clear on the criteria. Focus your more rigorous testing on the higher risk functions and less rigorous testing on the lower risk functionality. I recommend testing all functionality you expect users to use so that you know that it will work for your company’s intended use. And I recommend training users on how you expect them to use the system functionality for their specific role.

3. Are regulatory agencies opening up inspections for Part 11 for non-predicate rule systems? Or has the interpretation of “predicate rule” changed to be very very broad?

I haven’t seen this happen and if anything, FDA has had a narrower focus on what they seem to care about during their inspections. But, if they see a problem, they will dig deeper.

4. If we want to qualify equipment that has embedded softwre which controls the equipment operation, from the CSA (computer software assurance) side, do we need code or configuration level validation or just the equipment functional requirement without mentioning software details? I understand we need to document the software version that was installed for the equipment to function and access control requirement (not 21 CFR 11 as is), this my current understanding. I would like to specific guidance on this topic.

So much equipment is managed and controlled by computer systems / software that it’s hard to ignore it and is generally not recommended. While equipment validation people tend to be different from computer validation people, we should be taking a holistic approach to validating / qualifying equipment that has software as a core component of the equipment. If the equipment cannot be operated without the software, it needs to be considered part of the equipment and the software functional requirements should be a part of the equipment validation. The old ways of simply documenting the version of the software is no longer the best practice. I’ve seen 483s for HPLCs where the software was ignored.

5. Some suppliers are better than others in documentation — can you share few names — your favorites?

As I mentioned during the webinar, Arena PLM used to be really good about what they provided to their customers to support their customers’ individual validation efforts and support change control for each release. As for other companies, I don’t have a good list. There are so many systems that we implement to support life sciences companies from quality, manufacturing, clinical, regulatory, supply chain, lab systems, etc. that it’s nearly impossible to keep up with all of them.

With that being said, when you do a vendor audit or assessment, request a SOC2 report from them. And if they rely on AWS, Azure, or GCP for their infrastructure, request the SOC2s for those to understand the infrastructure controls. Also ask for the agreements with the infrastructure providers to understand the the service level agreements (SLAs).

6. Are there data security certifications for vendors?

I haven’t seen any as a standard in life sciences and honestly I don’t really pay attention to specific certifications, including ISO, but I do like to see SOC2 reports when I am performing a vendor audit..

7. Please comment on system updates that vendors administer — how to react?

As I mentioned during the webinar, there are a couple of different types of updates that a vendor will perform. For the periodic release updates, I recommend ensuring that you get what you need from the vendor to perform your internal impact assessment as part of your change control process. I also recommend generating a release procedure for each system based on what you know the vendor will provide and your internal change control process. It makes it easier for the folks who have to adhere to it post go live.

For updates that are more frequent and where it would be very difficult to keep up with from a proactive change control perspective (and if you don’t get the info from the vendor in advance), I recommend putting into place an operational procedure for each system that includes periodic reviews of these types of updates. As I mentioned in the webinar, there was a company that had a custom program that sat on GCP where updates were applied automatically. We assessed the risk and determined that a monthly review of the changes was acceptable as long as we documented the review, opened deviations for any findings, and had a deviation procedure in place to capture issues as they occurred so that we could potentially tie back to one of the updates if appropriate.

8. Should we identify functional risks associated with the requirements or the intended use of the System as a whole?

There are at least two risk assessments:

— system level: done at the very beginning and then updated as additional information is gathered regarding the vendor, processes, etc.

— functional level: done based on the functional requirements to determine what level of testing / verification is to be performed for the functionality. l

9. What are the most common challenges in CSV/CSA activities?

Organizational support for computer validation, not allocating appropriate resources, lack of understanding and experience in Quality, taking a one-size-fits-all approach, signing agreements prior to assessing the vendor, not having SOPs in place to govern system selection, computer validation, etc. to support controlled systems. I could go on and on and on…

10. What is important in the validation process to prevent unauthorized access to data in a system or computer?

It’s less about the validation process and more about the requirements and configuration. Make sure there are specific functional requirements for security and access that are consistent with your company’s security and password SOPs. Manage access through roles if possible and assign roles to users, providing (narrowly) what they need access to. Start tight and then loosen as users require more access to do their jobs. Verify access during the testing process. Make sure users / access are one to one with no shared user IDs and strong password requirements. Understand how the vendors (for SaaS or externally hosted) manage segregation of data and access and know who has access to your system, what their access is, and the vendor’s procedures around managing that access.

11. How do you know if your CSV or CSA activities are the right size for an organization?

This is a hard one to answer. From a compliance perspective, you won’t know until you are inspected. From a business perspective, if people are able to do their jobs effectively and the system uptime and availability are good, and there are few disruptions, you’ve probably done a good job.

12. Can you please elaborate test environment validation?

Assuming I understand this question, before changes are released into production, they should be tested in a separate test environment or instance. I don’t generally validate a test environment but I do recommend making sure controls are in place to ensure that the test environment is in a state as close to the production environment as possible so that you can reasonably rely on the testing performed in it.

13. Any input into risk assessments for SaaS vendor periodic re-audit? Do you see companies having a QAA with SaaS vendors?

Assuming QAA means Quality Assurance Agreement, most of the time I see SLAs (service level agreements). Most SaaS vendors, even those operating exclusively in the US, are tech companies first and have agreement structures in line with the tech industry. If there is specific language that your company requires in an SLA to meet your QAA requirements, you can always request them during the contract process. Make sure to include that you are allowed to perform audits on a specific frequency of your choosing and in the case of significant issues (however you define it), that you are able to perform more frequent audits.

As for the risk assessment for a re-audit, this is a good question. I’m assuming that your company has an external audit procedure in place that probably doesn’t specifically address IT solution providers, including SaaS (I haven’t seen any biotech companies that have actually incorporated this into their SOPs) but the philosophy should be similar to what you have for CMOs or other (assuming) high risk vendors. I tend to put into the validation plan that a re-audit will be performed bi-annually unless otherwise specified in another SOP or issues warrant an audit more frequently.

Since IT systems / SaaS solution providers tend to be outside the scope of what QA tends to like to pay attention to, or has been comfortable with historically, I believe there is a gap in this area for a lot of companies.

Other Resources

During the webinar I mentioned that I’d written a number of blog posts on computer validation and software assurance. They can be found on Medium under Terri Hanson Mead (I have a publication).

While the following isn’t a complete list, these are some that I mentioned during the webinar.

SaaS System Validation: Validating for Intended Use

SaaS Vendor Audits: Sample Audit Agenda

SaaS Vendors’ CSA/CSV Responsibilities in Life Sciences

Ticking Time Bomb: SaaS in Life Sciences

IT SOPs for Controlled Systems in Life Sciences

Quality and Compliance are Corporate Initiatives

Cybersecurity Insurance is Not a Cybersecurity Strategy

Have Questions or Require Assistance?

Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.

About the Author

Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.