Software patches are issued periodically by virtually every (major) software producer on the planet. From Microsoft to Apple; Adobe to Corel. Patching is required to fix faults, increase functionality and generally just iron out faults or correct things that could be better, nevermind security!
Security
Security is the most critical area of computing nowadays and being secure is the most important business requirement out there. Patches are released to enhance security / “patch” a vulnerability or to deliver a bug fix or enhancement; this is basically a situation such that patches are either reactive or proactive.
Patches
Reactive patches are plugging holes that have been exploited by hackers or “cyber terrorists” – some new trojan has found yet another back door that will cripple your business. React now and install the new patch! Microsoft have released it so it’s absolutely necessary. Is this really the case? No it is not.
They have probably not tested it with your DeltaV or LIMS system – how will the patch affect your business? What if it mandates a new .NET framework that your propriertry application software can’t understand?
Reaction is risk in the world of patching the minimum risk is losing performance – the greater risk is losing production and/or reputation.
Development System
Where possible, make sure you have a test or development system to implement patch installation prior to commitment to the real thing, give them a [documented] few days and then install them (under change control whilst observing risk management procedures) – don’t let a problem be a disaster and consider that if you already have a secure system you might not be at risk of the risk.
Whether the patch is required or not, it should be assessed to determine whether the business will benefit from the application of the patch, or whether a risk situation is imminent. If necessary a formal risk assessment should be carried out with robust mitigation options on the table.
Change Management
Regardless of the urgency of the situation, a change management process should be used that includes a roll-back plan as well as a reasonable level of testing (in accordance with the risk category). Does the patch have to be applied to the production system first?
Or is there a smaller area that can be used, e.g. a development system or just a subset of the overall set of computers that will require the patch? In any case, release the patch slowly whilst testing continuously to make sure the change control details not only how to do the installation, but also how to revert back and make sure that the systems can be reinstated to the post-patch condition.
Conclusion
Finally, make sure someone else has approved the change – in writing. If you’re in a non-controlled area then try and make a change logbook or something just so it is evident what has been done, when and by whom; not only are you covering your own back and not being liable to bringing a plant down, you are in a position to recover another error by using the logbook as a tool, e.g a shiftworker is told to make a change that fails a few days later (even dodgy patches are released to the market) – you are back in work and you can revert the change by looking at the change log and then following the rollback plan in the change control pack.
