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.

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,

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.