ICT systems‘ acquisition, development and maintenance procedure

ICT systems‘ acquisition, development and maintenance procedure

Purpose and Scope

Financial entities are required to develop, document, and implement a formal ICT systems’ acquisition, development and maintenance procedure that governs:

  • the testing and
  • the approval

of all ICT systems before first use and after every maintenance activity.

This procedure is part of the safeguards necessary to preserve availability, authenticity, integrity and confidentiality of data and ICT systems.

Mandatory Requirements of the Procedure

Testing and Approval Prior to Use and Post-Maintenance

The procedure must ensure that:

  1. All ICT systems—whether newly acquired, internally developed, modified, upgraded, patched, or otherwise maintained—
    are tested and approved prior to being put into use.
  2. Testing and approval must be conducted again after any maintenance, including but not limited to:
    • software updates,
    • hardware updates,
    • configuration changes,
    • firmware updates,
    • code changes,
    • system reconfigurations.

This requirement directly references Article 8(2)(b)(v)–(vii), meaning it must cover:

  • requirements for separation of production and non-production environments,
  • testing in controlled environments,
  • strictly limited and justified cases of testing in production environments, with pre-approval.

Risk-Based Testing Depth

The level of testing must be commensurate with:

  • the criticality of the affected business procedures, and
  • the criticality of the ICT assets involved.

This introduces a mandatory mapping between:

  • the criticality classification under Article 8(1) DORA,
  • the entity’s ICT architecture,
  • business-impact assessments,
  • and the required technical/functional, performance, security, and resilience tests.

Verification of Adequacy and Performance of ICT Systems

Testing must be designed to verify that:

  • new ICT systems perform as intended,
  • systems meet functional and non-functional requirements,
  • resilience, confidentiality, integrity and availability requirements are met, and
  • internally developed software meets quality standards, including error-handling, coding quality and secure-development practices.

The obligation explicitly includes quality assurance for internally developed software.

Additional Requirements for Central Counterparties (CCPs)

For central counterparties, the procedure must additionally ensure that the design and execution of testing involve, as appropriate:

  • (a) clearing members and clients
  • (b) interoperable CCPs
  • (c) other interested parties

This reflects the systemic importance of CCPs and ensures interoperability, market integrity, and systemic-risk mitigation.

Additional Requirements for Central Securities Depositories (CSDs)

For central securities depositories, the testing design and execution must involve, as appropriate:

  • (a) users
  • (b) critical utilities and critical service providers
  • (c) other CSDs
  • (d) other market infrastructures
  • (e) any institution with which the CSD has identified interdependencies in its business continuity policy

These requirements ensure alignment with the CSD’s settlement ecosystem and critical infrastructure dependencies.

Article 16 (2) RTS RMF

RTS RMF