+RTS ICT Risk Management T. II Ch. I Sec. 7 Art. 17 , 1

1. Overview

RTS ICT Risk Management T. II Ch. I Sec. 7 Art. 17 , 1

1. As part of the safeguards to preserve the availability, authenticity, integrity, and confidentiality of data, financial entities shall include in the ICT change management procedures referred to in Article 9(4), point (e), of Regulation (EU) 2022/2554, in respect of all changes to software, hardware, firmware components, systems, or security parameters, all of the following elements:

  • (a) a verification of whether the ICT security requirements have been met;
  • (b) mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes;
  • (c) a clear description of the roles and responsibilities to ensure that:
    • (i) changes are specified and planned;
    • (ii) an adequate transition is designed;
    • (iii) the changes are tested and finalised in a controlled manner;
    • (iv) there is an effective quality assurance;
  • (d) the documentation and communication of change details, including:
    • (i) the purpose and scope of the change;
    • (ii) the timeline for the implementation of the change;
    • (iii) the expected outcomes;
  • (e) the identification of fall-back procedures and responsibilities, including procedures and responsibilities for aborting changes or recovering from changes not successfully implemented;
  • (f) procedures, protocols, and tools to manage emergency changes that provide adequate safeguards;
  • (g) procedures to document, re-evaluate, assess, and approve emergency changes after their implementation, including workarounds and patches;
  • (h) the identification of the potential impact of a change on existing ICT security measures and an assessment of whether such change requires the adoption of additional ICT security measures.

1.1 References

1.2 Identified Requirements

1.3 Related Standards

2. Identified Requirements

Requirements

3. Related Standards

Standards
NOREA Change Procedures
Ensure that all changes to software, hardware, firmware components, and systems, along with security parameters, are appropriately placed and scoped. Document and communicate change details, including the purpose and scope of the change, the implementation timeline, and expected outcomes. Define clear roles and responsibilities to ensure that changes are defined, planned, transitioned, tested, and finalized in a controlled manner. Additionally, establish effective quality assurance procedures. Implement mechanisms to maintain independence between the functions that approve changes and those responsible for requesting and implementing them.
NOREA Security Requirements
Identify the potential impact of a change on existing security measures and assess whether additional security measures are required for its implementation. Verify that security requirements have been met for all implemented changes. Establish fallback procedures and assign responsibilities for aborting changes or recovering from changes not successfully implemented.
NOREA Emergency Change Management
Define procedures for documenting, reevaluating, assessing, and approving the implementation of emergency changes, including workarounds and patches.
NOREA OTAP Implementation
Ensure segregation of production environments from development, testing, and other non-production environments, encompassing all components of an environment. This also includes requirements to conduct the development and testing in production environments. Ensure that the instances in which testing is performed in production environment are clearly identified, justified, for limited periods of time approved by the relevant function.
Impressum