The first step in ensuring effective and reliable application of updates is to develop a solid patch management policy that spells out all the processes involved, along with all the participants and their responsibilities.
This article lays out the essential components for an effective policy and provides examples of how they should be written.
1. Scope
This section specifies which systems the policy applies to. It can list specific systems or simply state that all systems fall under the policy.
This patch management policy (hereinafter, “the Policy”) defines the process for updating and storing versions of all test and production information systems (hereinafter, “the Systems”).
2. Goal
This section states the purpose of the policy.
This goal of the Policy is to strengthen the company’s information security by keeping the Systems as up to date as possible and to minimize maintenance errors in order to minimize the likelihood of malicious actors successfully using exploits to attack the company. The Policy is also intended to ensure the smooth operation of the Systems.
3. General Provisions
This section summarizes the update process and assigns responsibility for each system.
Members of the Cybersecurity (CS) department are responsible for updating the Systems. This work is to be performed in conjunction with the Information Technology (IT) department.
The update process includes:
- Identifying all software, information, objects, databases, and hardware in the Systems that require updates
- Identifying the core stakeholders for each System
- Identifying maintenance days for each System
- Obtaining formal approval from the System stakeholders before starting the update process
- Gaining temporary, least-privileged access to each target System to perform its updates
- Gaining authorization from the System owner for updates in the test environment
- Checking the test environment’s availability and functionality after the update, and rolling back the changes if something goes wrong
- Gaining authorization from the System owner for updates in the production environment
- Checking the production environment’s availability and functionality after the update, and rolling back the changes if something goes wrong
- Monitoring the update process
- Ensuring that the System’s technical documentation is revised after each update
4. Requirements
This section describes the update process in detail.
4.1 Request for Update
- Update requests are submitted electronically by the CS department in the project management system. The request must include:
- The name of the update officer from the CS department
- The name of the System and its owner
- The name of the update operator from the IT department
- Date of test environment update
- Date of production environment update
- Update details and purpose
- Possible system downtime time period
- Brief technical description of the update
- Each update request is recorded in the project management system.
- The update must be approved by the Systems owner.
- The update request is assigned to the responsible IT department.
- The CS department must keep an update control log that registers update requests and tracks the status of requests.
4.2 Updating the Test Environment of the System
- The CS department sends the update package or a link to the updates to the IT department via the project management system.
- Updating of the test environment of the System is performed by the IT department in cooperation with the CS department at the scheduled date and time.
- Representatives of the IT department check that the test System works as intended:
- If the test environment of the System is updated successfully, the update is recorded in the project management system.
- If problems are found, they are recorded in detail along with how critical they are. The CS department and the System owner analyze this information, assesses the risk, and determines whether to install the update in the production environment and records the decision and reasoning in the project management system.
- After the release of a new software version, the IT department checks the update again in the test environment to exclude new errors and records the results in the project management system.
- The System owner acknowledges the conclusion of the test environment update.
4.3 Updating the Production Environment of the System
After functionality verification in the test environment and approval of the System owner, the IT department finalizes the upgrade plan for the production environment.
- The plan details the date of upgrade, its duration, participants, and the list of recipients to be notified.
- The plan is coordinated with the CS department and the System owner.
- After approval of the plan by the IT department, an announcement of the unavailability of the System and planned work shall be sent by email to all System users at least 24 hours in advance.
- The IT department updates the prod environment of the System in the presence of the System owners.
- The IT department and the System owner check that the System works as intended. If problems are found, the System owner decides how critical they are to the operation and approves a rollback if needed.
- The IT department records the results in the project management system, and notifies the CS department.
5. Version History
This section tracks all changes to the patch management policy.
Version number. Date of change. Name and position of the person who made the change.
Patch Policy Configuration Management
Simply writing a patch management policy won’t make patching more reliable or less time consuming — you need an automated patch management solution.
Action1 enables IT teams to actually implement their organization’s patch management policy and automate the patch distribution process. For example, they can efficiently:
- Deploy updates either upon explicit approval or automatically after a specified number of days since their release
- Schedule a reboot for a convenient time or choose to skip it altogether
- Deploy updates to all endpoints or to specific groups of machines
- Determine the update delivery schedule to avoid business disruptions and lost productivity
See for yourself just how easy effective patch management can be. You can use Action1 on 100 endpoints free of charge with no functionality limitations.
