6.4 Change management, repairs and maintenance

Requirement

The relevant entities shall apply change management procedures to control changes of network and information systems. Where applicable, the procedures shall be consistent with the relevant entities’ general policies concerning change management.

Guidance

• Take into account industry-recognised and national standards when developing the change management procedures (54).
• Consider the following elements for the procedures (indicative, non-exhaustive list):
  • request for change,
  • risk assessment,
  • criteria for categorisation and prioritisation of changes:
    • associated requirements for the type and scope of the tests to be carried out and
    • the approvals to be obtained;
  • requirements for performing rollbacks; and
  • documentation of the changes and approval of changes.
• The change management procedures may allow different workflows depending on the criticality of the system, the scope of the change and the urgency (e.g. put in place an ‘emergency intervention workflow’).
• For each change, record the steps of the procedure followed.
• Review and approve changes following the change management procedures, prior to implementing them.
• Implement and test change management procedures to make sure that changes to networks and information systems are always done in a predefined way.
• Where appropriate, establish a change advisory board (CAB) to oversee and approve changes. The CAB should evaluate change requests based on risk, impact, resource requirements and alignment with business objectives.

Examples of evidence

• Documented change management procedures for network and information systems that are based on standards or good practices.
• For each relevant change, a record describing the steps and the result of the change.
• A system maintenance procedure that addresses:
  • purpose;
  • scope;
  • roles;
  • responsibilities;
  • management commitment, if applicable;
  • coordination among different organisational units; and
  • compliance.
• Logs that record the dates and outcomes of the periodic reviews of the change, repair and maintenance procedures.

Requirement

The procedures referred to in point 6.4.1. shall be applied for releases, modifications and emergency changes of any software and hardware in operation and changes to the configuration. The procedures shall ensure that those changes are documented and, based on the risk assessment carried out pursuant to point 2.1, tested and assessed in view of the potential impact before being implemented.

Guidance

• Consider a mandatory integrity check before installing and deploying new software.
• Ensure, where appropriate, that changes are done in an authenticated, authorised and non-repudiating manner.
• Test and validate changes before they are implemented in operational systems, where applicable. Where appropriate, a security impact analysis may be performed in a separate test environment before implementation in an operational environment.
• Take all necessary precautions before making changes (back up images, for instance).
• Schedule, perform, document and review records of maintenance and repairs on system components in accordance with the supplier’s specifications and/or the entity’s requirements.
• Ensure that changes are only allowed with approved tools and that their execution is documented.
• Restrict the use of maintenance tools to authorised personnel only.

Examples of evidence

• Logs and records of past (new) software installations.
• Evidence that MFA is in place for activating change, repair and maintenance procedures, where applicable.
• Test plans and results that demonstrate the implementation and effectiveness of the change, repair and maintenance procedures.
• If the entity utilises change management tools, evidence that these tools enforce the use of approved resources only and mandate documentation for each change.
• Access control lists (ACLs) to verify that access to the tools is in line with the access control policy.

Requirement

In the event that the regular change management procedures could not be followed due to an emergency, the relevant entities shall document the result of the change and the explanation for why the procedures could not be followed.

Guidance

• Where appropriate, integrate the pullback scenario (55) into the change management procedures.
• Assess the risks from legacy systems and upgrade existing legacy systems to include security mitigating measures in case appropriate security cannot be achieved.
• Make sure that regular change control procedures that could not be followed due to an emergency change are applied immediately after the emergency change.

Examples of evidence

• Documentation with specific pullback plans.
• Logs and records of past change requests with details of (indicative, non-exhaustive list):
  • the change,
  • reason for emergency,
  • approval,
  • reason for delay,
  • follow up actions and
  • how to revert the system to a previous stage if the change fails.
• Logs and records from past legacy system upgrade that contain risk assessments and the reasoning for the change.

Requirement

The relevant entities shall review and, where appropriate, update the procedures at planned intervals and when significant incidents or significant changes to operations or risks.

Guidance

• Review the change management procedures at least once every two years.
• Make sure that the management procedures cover planned and unplanned changes and the development phase, when applicable.
• Ensure that the process is not bypassed.

Examples of evidence

• Review plans or schedules.
• Up to date change management procedures, review comments and/or change logs.
• Evidence of approval and monitoring of maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location.
• Logs of all changes made to the procedures, including details, approvals and implementation dates.
• Audit trails and compliance records from internal and external audits.
• Logs of significant incidents to confirm whether they include documentation of reviews and updates to the change, repair and maintenance procedures.
• Reports from post-incident reviews that document any necessary adjustments to the procedures following significant incidents.
• Records showing how changes and updates to the procedures were implemented and reviewed.

Tips: guidance

• Perform and log: (a) changes to, (b) maintenance of and (c) repairs to network and information systems, with approved and controlled tools.
• Put change management procedures in place according to licensing agreements.
• Upon changes to assets, update the asset inventory (Annex to the regulation, point 12.4) and documentation.
• Upon changes to risk management measures, update the risk treatment plan (Annex to the regulation, point 2.1.1).
• Inform the customer of significant changes to network and information systems that affect the services offered. This information only needs to be provided if it is beneficial for customers.
• Ensure availability of the required maintenance skills, resources and spare parts, including external support.
• Prevent the unauthorised removal of maintenance equipment containing information related to the entity by (indicative, non-exhaustive list):
  • verifying that no information related to the entity is contained in the equipment;
  • sanitising or destroying the equipment;
  • retaining the equipment within the facility; or
  • obtaining an exemption from authorised personnel or roles explicitly authorising removal of the equipment from the facility.
• Provide remote access via out-of-band (OOB) connection in the event that the standard connection does not work.
• Regularly test OOB connections to ensure they function as expected during an outage.
• If an incident, in the sense of Article 23 of the NIS2 Directive, involves subsequent actions that entail system changes, then notify the competent authorities of these changes in accordance with the national reporting procedure.

Tips: examples of evidence

• Evidence that MFA is in place for remote change, repair and maintenance procedures.
• Logs and records that prove the use of approved tools.
• Evidence that the procedures mention the licencing agreement.
• Up-to-date asset inventory.
• Up-to-date risk-treatment plan.
• Documentation of a customer update on significant changes.
• Evidence of previous training on change management and system maintenance.
• Evidence of sanitisation procedures.
• Evidence that the entity maintains a spare parts for key components of its network and information system.
• Notifications to defined personnel or roles of the date and time of planned maintenance.
• Network architecture diagram that proves the existence of OOB connections.