Source: OJ L, 2024/1774, 25.6.2024

Current language: EN

Article 17 ICT change management


Summary What does Article 17 of the RTS on ICT risk management framework say?

This article elaborates on the ICT change management procedures that financial entities must have in place, building directly on the requirement in Article 9(4)(e) of DORA (Regulation (EU) 2022/2554).

It sets out the minimum content those procedures must cover for any change to software, hardware, firmware, systems, or security parameters — encompassing everything from roles and responsibilities, documentation, and fall-back procedures, to the handling of emergency changes both during and after their implementation.

The article also imposes an additional, more demanding obligation on central counterparties and central securities depositories specifically: following significant ICT system changes, they must conduct stringent stress-condition testing and involve relevant external parties in that process.

Important points:

  • Include all mandated elements — such as independence of approval functions, fall-back procedures, and impact assessments on existing security measures — in your ICT change management procedures.
  • Emergency changes must be covered by dedicated procedures, protocols, and tools, and must be documented, re-evaluated, assessed, and approved even after their implementation.
  • Central counterparties and central securities depositories are required to conduct stringent stress-condition testing after significant ICT changes, involving clearing members, clients, users, and other relevant external parties as appropriate.

Springlex's summary of the article, a reading aid, not a substitute for the legal text.

    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:

      1. a verification of whether the ICT security requirements have been met;

      2. mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes;

      3. a clear description of the roles and responsibilities to ensure that:

        1. changes are specified and planned;

        2. an adequate transition is designed;

        3. the changes are tested and finalised in a controlled manner;

        4. there is an effective quality assurance;

      4. the documentation and communication of change details, including:

        1. the purpose and scope of the change;

        2. the timeline for the implementation of the change;

        3. the expected outcomes;

      5. the identification of fall-back procedures and responsibilities, including procedures and responsibilities for aborting changes or recovering from changes not successfully implemented;

      6. procedures, protocols, and tools to manage emergency changes that provide adequate safeguards;

      7. procedures to document, re-evaluate, assess, and approve emergency changes after their implementation, including workarounds and patches;

      8. 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. After having made significant changes to their ICT systems, central counterparties and central securities depositories shall submit their ICT systems to stringent testing by simulating stressed conditions.

    2. Central counterparties shall involve, as appropriate, in the design and conduct of the testing referred to in the first subparagraph:

      1. clearing members and clients;

      2. interoperable central counterparties;

      3. other interested parties,

    3. Central securities depositories shall, as appropriate, involve in the design and conduct of the testing referred to in the first subparagraph:

      1. users;

      2. critical utilities and critical service providers;

      3. other central securities depositories;

      4. other market infrastructures;

      5. any other institutions with which central securities depositories have identified interdependencies in their ICT business continuity policy.

We're continuously improving our platform to serve you better.

Your feedback matters! Let us know how we can improve.

Found a bug?

Springflod is a Swedish boutique consultancy firm specialising in cyber security within the financial services sector.

We offer professional services concerning information security governance, risk and compliance.

Crafted with ❤️ by Springflod