S 3.66 Basic terminology of patch and change management

Initiation responsibility: Head of IT, Change Manager, IT Security Officer

Implementation responsibility: Change Manager

During the patch and change management process, diverse updates and improvements are made available, controlled, and administered in the production environment. In this regard, numerous terms have been established. The persons responsible for implementing the process must be familiar with these terms.

Very different designations in use for versions. This can be attributed to the fact that there is no uniform, binding, comprehensive standard for the terminology. During versioning, the products to be created, e.g. hardware or software, pass different stages of development. Due to the inaccurately defined terms, it is recommendable to use a glossary within the organisation in order to ensure a uniform understanding of all technical terms.

The first executable version of a product is often called alpha version. The alpha version often serves for internal use, e.g. in order to demonstrate that a software project is feasible. Therefore, it normally already includes the most important basic functions.

A beta version is a still unfinished product version released by the developer for testing or pre-sale purposes. The essential functions of the product are already present, but not tested with the utmost depth. Beta versions are distributed to so-called beta testers who test the functionality and usability of the product and report any errors to the developers. Normally, numerous programming errors are found in software.

Within the framework of software development, release candidate (RC) refers to a final test version. In this version, all functions contained in the final version of the software are available. This version serves for final system or product testing. Further RCs are only released if severe quality issues are determined during testing.

The finished and released version of a software is called release or stable and normally given a version number additionally. Since the production of the media (CDs or DVDs) is also started at this point in time, the term release to manufacturing (RTM) is often used.

Many software developers have released mechanisms for handling software corrections. In these, the following terms are not always used consistently. However, they provide the required overview of the terminology in this topic.

Software corrections are released in order to eliminate errors in already released software. A patch is a general software update eliminating malfunctions in a software. Initially, such an update is not critical and not security-relevant. If the update is relevant for the security of the software, i.e. if it closes a security gap, it is often called security patch. Often, a degree of severity is specified for a security patch. This normally refers to the manufacturer's opinion regarding the severity of the security gap the security patch is intended to close. If the update is installed to correct an essential function of the software that is not necessarily security-relevant, for example an incorrect calculation, this is often called critical update.

Another release of the manufacturers, which, however, only relates to specific customer situations and is often only made available in the presence of a valid support agreement or only based on support queries, is called hotfix. A hotfix may be an individual packet consisting of one or several files intended to eliminate a problem in a product.

On the contrary, a service pack is a cumulative collection of hotfixes, security patches, critical updates, and updates released since the product was launched and made available to the general public.

The period until service packs are released often is very long. Furthermore, a summary may be useful for the provision of the host of software corrections available in the meantime. Therefore, some manufacturers now and then release so-called update roll-ups. The update roll-ups constitute a collection of security patches, critical updates, updates, and hotfixes offered cumulatively or for an individual product component, e.g. a web server.

Once service packs have been released, the product series available then are often given a higher number behind the decimal point. This is intended to document that the software products already contain all corrections available up to this point in time. Some manufacturers also refer to this as an integrated service pack.

Due to the different demands from customers directed at the manufacturer, the manufacturer often feels compelled to integrate new options (features) into the product in order to expand the product's functionality. The functionality extensions are normally offered to all customers with valid contractual relations to the manufacturer (support agreement, update agreement, Software maintenance agreement, or such like) as a feature pack. The new features are normally integrated into the next product version.

In practice, two kinds of changes to IT components are common. Standardised changes and changes that must pass the patch and change management process.

Standardised changes include changes to applications and IT systems for which exact procedural instructions exist and which are approved in advance by the Change Manager.

The written procedural instructions must guarantee that the risk related to the change is negligible. The change can be performed without having to consult the Change Manager again. This way, the workload for the persons responsible for the process is reduced significantly.

Incidents are one of the reasons for hardware or software changes. An incident is a deviation from standard operations of an IT service (service) which actually or potentially reduces the service quality or even interrupts the service.

If the cause of the incident cannot be discerned, there is a problem to be investigated more thoroughly. In ITIL, the term problem is used to refer to one or several similar incidents with unknown causes. If the underlying cause is determined and an way to eliminate or bypass the problem is found, a problem turns into a known error. The solution is documented in a request for change (RfC) and implemented under the supervision of the Change Manager.

In addition to the specific terminology for patch and change management (for example from ITIL), the persons responsible for patch and change management should be familiar with the terminology for information security.