![]()
Stage 1: Finding
Any IT professional worth a weight will have a comprehensive network inventory before implementing a patch management process and conduct an IT evaluation to understand the types of devices, hardware, systems, operating systems, OS versions and software and application applications in use throughout your enterprise. As companies grow, IT resources are tightened and systems are often neglected and forgotten. The sheets are hard to keep up and so the many systems and programs used can be lost from internal IT.
Step 2: Priority & Categorization
With good understanding of our IT environment and infrastructure, our systems and/or users need to be segmented according to their risk or priority. At the user’s level, the C-Suite and users who often have to share, download, or install programs should be given priority. In particular, users who often share documents by e-mail or online can be considered as ‘high risk,’ as they are more vulnerable to external threats. Looking at hardware, you could give preference to a laptop that is seldom used to serve and critical business hardware of the company.
Step 3: Creation of patch management policies
We then develop patching requirements by determining which systems, users and software have to be patched, under which conditions and in the frequency of upgrading of these systems/users. You can make sure, for example, that certain systems or users (liked patching employee laptops weekly) are patched more regularly and automatically compared to a server or network firewall, which could take more manual and less frequent updates.
Step 4: New patch and vulnerability monitoring
Modern firms use a range and each one of their patch releases and vulnerability communications schedules, in terms of systems, software and digital products. Whilst time consuming, it is important that your team takes the time to catalog each technology vendor, its main vulnerability and product notifications page (e.g. Sonic Wall Product Notifications). The creation of an organized patch release or notification feed saves your team over a year for hours (maybe days). The second (sometimes fourth) Tuesday of each month patches for Microsoft’s “patch Tuesday,” for example.
Step 5: Testing of patches
Create a non-production test environment, deploy the patch, and track problems of incompatibility or performance before rolling out patches, especially with mission critical elements, like business servers. We recommend testing patches on a small segment (2 users) to evaluate if any negative effects occur if it is not possible to create a test environment.
Step 6: Management Settings
Document the desired changes and results after the testing phase. If your roll-out goes awry, unintended modifications can be identified and resolved quickly.
Step 7: Patch Out
You will now like to follow the patch management policy established in step three to implement it as necessary, once your team validates the patch.
Step 8: Audit of patches
Take a moment to identify any missed or pending patches, after patch rollout. Monitor these for problems of incompatibility. We advise two tech knowledgeable end users to provide feedback if necessary.
Phase 9: Reporting
The IT is no different for each unit of business. Prepare a monthly patch compliance report to share with the C-Suite and executives when needed. This will ensure that everyone understands the importance and benefits of patch management.
Step 10: Checking, optimizing and repeating
Like most business processes – review, update and repeat steps from 1 to 9 on a regular basis. Look for the End-of-Life (EOL) systems, outdated hardware/machines, revise policy quarterly and, where necessary, revise your patch management policy in terms of effectiveness.
