ICT systems acquisition, development, and maintenance


  1. As part of the safeguards to preserve the availability, authenticity, integrity, and confidentiality of data, financial entitiesas defined in Article 2, points (a) to (t) shall develop, document and implement a policy governing the acquisition, development, and maintenance of ICT systems. That policy shall:

    1. identify security practices and methodologies relating to the acquisition, development, and maintenance of ICT systems;

    2. require the identification of:

      1. technical specifications and ICT technical specifications, as defined in Article 2, points (4) and (5), of Regulation (EU) No 1025/2012;

      2. requirements relating to the acquisition, development, and maintenance of ICT systems, with a particular focus on ICT security requirements and on their approval by the relevant business function and ICT asseta software or hardware asset in the network and information systems used by the financial entity owner in accordance with the financial entity’s internal governance arrangements;

    3. specify measures to mitigate the risk of unintentional alteration or intentional manipulation of the ICT systems during the development, maintenance, and deployment of those ICT systems in the production environment.

  2. Financial entitiesas defined in Article 2, points (a) to (t) shall develop, document, and implement an ICT systems’ acquisition, development, and maintenance procedure for the testing and approval of all ICT systems prior to their use and after maintenance, in accordance with Article 8(2), point (b), points (v), (vi) and (vii). The level of testing shall be commensurate to the criticality of the business procedures and ICT assetsa software or hardware asset in the network and information systems used by the financial entity concerned. The testing shall be designed to verify that new ICT systems are adequate to perform as intended, including the quality of the software developed internally.

    Central counterpartiesa central counterparty as defined in Article 2, point (1), of Regulation (EU) No 648/2012 shall, in addition to the requirements laid down in the first subparagraph, 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 counterpartiesa central counterparty as defined in Article 2, point (1), of Regulation (EU) No 648/2012;

    3. other interested parties.

    Central securities depositoriesa central securities depository as defined in Article 2(1), point (1), of Regulation (EU) No 909/2014 shall, in addition to the requirements laid down in the first subparagraph, involve, as appropriate, 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 depositoriesa central securities depository as defined in Article 2(1), point (1), of Regulation (EU) No 909/2014;

    4. other market infrastructures;

    5. any other institutions with which central securities depositoriesa central securities depository as defined in Article 2(1), point (1), of Regulation (EU) No 909/2014 have identified interdependencies in their business continuity policy.

  3. The procedure referred to in paragraph 2 shall contain the performance of source code reviews covering both static and dynamic testing. That testing shall contain security testing for internet-exposed systems and applications in accordance with Article 8(2), point (b), points (v), (vi) and (vii). Financial entitiesas defined in Article 2, points (a) to (t) shall:

    1. identify and analyse vulnerabilitiesa weakness, susceptibility or flaw of an asset, system, process or control that can be exploited and anomalies in the source code;

    2. adopt an action plan to address those vulnerabilitiesa weakness, susceptibility or flaw of an asset, system, process or control that can be exploited and anomalies;

    3. monitor the implementation of that action plan.

  4. The procedure referred to in paragraph 2 shall contain security testing of software packages no later than at the integration phase, in accordance with Article 8(2), point (b), points (v), (vi) and (vii).

  5. The procedure referred to in paragraph 2 shall provide that:

    1. non-production environments only store anonymised, pseudonymised, or randomised production data;

    2. financial entitiesas defined in Article 2, points (a) to (t) are to protect the integrity and confidentiality of data in non-production environments.

  6. By way of derogation from paragraph 5, the procedure referred to in paragraph 2 may provide that production data are stored only for specific testing occasions, for limited periods of time, and following the approval by the relevant function and the reporting of such occasions to the ICT riskany reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology dependent tool or process, of operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment management function.

  7. The procedure referred to in paragraph 2 shall contain the implementation of controls to protect the integrity of the source code of ICT systems that are developed in-house or by an ICT third-party service provideran undertaking providing ICT services and delivered to the financial entity by an ICT third-parties service provideran undertaking providing ICT services.

  8. The procedure referred to in paragraph 2 shall provide that proprietary software and, where feasible, the source code provided by ICT third-party service providersan undertaking providing ICT services or coming from open-source projects, are to be analysed and tested in accordance with paragraph 3 prior to their deployment in the production environment.

  9. Paragraph 1 to 8 of this Article shall also apply to ICT systems developed or managed by users outside the ICT function, using a risk-based approach.