This is why you cannot validate commercial software – you have zero control over it. Without control, there is no validation.
And yet you still have to manage changes to the environment in which your electronic records exist. Remember, your personnel perform various regulated actions, undertake specific processes, and make decisions using those records (which are, in turn, reliant upon an IT infrastructure that is in a “state-of-control”). This is how IT compliance, and 21 CFR 11 compliance in particular, goes awry. Where do you start? How do you control an IT environ over which your vendors exert considerable influence?
In general, the best answer is make the decision that my clients have taken – to bring an outside expert to either run a Part 11 workshop for the firm, to help draft 21 CFR 11 validation protocols, to conduct a mock Part 11 audit, or some other means by which your site specific questions can be addressed.
In the context of dealing with a vendor who issues automated software updates, the best approach that I’ve seen over the past decade take a three-phase tact:
Compile a “pre-approved” change list that then goes through normal change control
Conduct quick, basic, retrospective testing when such updates are noticed AND they may have an impact to the electronic data
Have Quality audit to the above.
Number two – the quick, basic, retrospective testing – can get tedious and potentially allow for IT and Quality to start arguing over what should have been noticed, what should have been retrospectively tested, etc. Avoid this by agreeing on some common criteria. For instance, any patch that states upfront it “affects data stability” (from an old Microsoft patch for Windows a few years back), should get some testing. Another example is large service packs (in other words, if the patch is big enough for the vendor to change its CD/DVD press labels, it’s large enough for you to do some testing).
