Windows 10 Validation: How to Handle Validation of Monthly Patches/Updates

Q: I have a question about Windows 10 validation. In your FDA Auditing of Computerized Systems and Part 11 /Annex 11 class, you pointed out that the “environment” for software/hardware is important when it comes to validation, because a different environment may cause software to behave differently.

We are currently running Windows 7 on all our company computers, and we’ve found a way to handle patches and updates to meet our validation requirements. But we are considering upgrading to Windows 10, and we aren’t sure how to handle validation of its patches and updates.

As you know, updates under Windows 10 contain patches as well as functional updates that are applied every month. It’s not possible to split the updates between patches and functional updates. Also, we understand it is advisable to take the full update packages because they often include security protections.

So each month under Windows 10 we would have to review all affected applications to determine if a new validation is necessary. But because the list of functional updates is so long, it’s not really possible for us to judge all the functional updates contained in each monthly release. And we don’t have the validation resources to re-validate all our software every month.

As a result, we are evaluating the following approaches for upgrading to Windows 10:

  • Apply a risk assessment to determine if certain software does not depend on Windows. An example would be web-based software that only needs Internet Explorer to be displayed.
  • Apply a risk assessment to determine if validation isn’t necessary, even if the software does depend on Windows. For example, we can look at the compatibility matrix provided by the supplier.
  • Apply automated testing for software that is highly dependent on Windows. Manual testing would take too many resources.
  • Don’t upgrade at all — stay with Windows 7.

My questions for you are:

  1. Are we too strict with our definition of the software environment? Even for a SharePoint-based software, we wrote Windows 7 into the software environment.
  2. What would FDA auditors think about our proposed approach for Windows 10? Would they question why we wrote Windows 7 in our software environment for several years, but now we argue that we are not depending on Windows?
  3. Is a risk-based approach our best option?

A: First you define the computerized system. This includes the hardware and all the software — including the operating system — so writing in Windows 7 as your software environment was appropriate. It is part of the system by FDA’s definition.

To upgrade to Windows 10, taking a risk-based approach is best. For those systems that only need Windows 10 to open, you have a good argument. For the others, it will depend on the risk that something could go wrong that could not be detected and could cause your products to be adulterated.

Look at all your software from the perspective of what you actually use it for and what controls you have in place.

For example, you may use MS Word to update your SOPs. You read and review the revised SOPs before they are approved. You have the controls of the reviews prior to approval — so those are your controls should something happen as a result of Windows 10. You then store the SOPs in PDF format to assure they are not changed. You can always compare the PDF version to the Word version to assure that the operating system did not change the Word version.

So look at procedural controls you have in place that can mitigate a Windows 10 failing.

It’s always best to have a regression suite of tests you can run quickly after each update to assure that the update did not cause a problem

For systems that are highly dependent on the operating system or ones that have no procedural controls, it’s always best to have a regression suite of tests you can run quickly after each update to assure that the update did not cause a problem.

Automating the testing is a good idea for saving time and personnel resources. You should add to your procedures that any issue that arises after each update will be investigated to determine if the update was a possible cause of the issue/non-conformance.

If any of your software is not compatible with Windows 10, I’m not sure you can take the risk of going to Windows 10 for those systems.

FDA will understand that you have changed your thoughts on the operating system if you 1) document the decision, 2) do a good risk assessment, and 3) add any additional procedural controls you deem necessary to mitigate the monthly updates.  

You also could commit to doing a re-validation on a routine basis, such as every year or two if the updates change the functionality of Windows 10.

Answered by Jan Olson, Vice President of Regulatory and Quality Services for EduQuest, who served 22 years at the U.S. FDA as an expert field investigator and was the Director of Information Management Resources for FDA’s Atlanta regional office. Jan is the co-instructor of EduQuest’s FDA Auditing of Computer Systems and Part 11/Annex 11 Compliance training class.


Leave a Reply

Your email address will not be published. Required fields are marked *