Contents
- Procedures and controls for ICT change management
- Purpose and Scope
- Mandatory Elements of the ICT Change Management Procedures
- Verification of ICT Security Requirements
- Independence of Key Functions
- Roles and Responsibilities Across the Change Lifecycle
- Documentation and Communication of Change Details
- Fall-Back Procedures and Responsibilities
- Emergency Change Management Controls
- Post-Implementation Documentation and Re-Approval of Emergency Changes
- Impact Assessment on Existing ICT Security Measures
- Additional Requirements for CCPs and CSDs
- Article 17 RTS RMF
- Article 9 (4)(e) DORA
Procedures and controls for ICT change management
Purpose and Scope
Financial entities must establish documented ICT change management procedures and controls that ensure all changes to:
- software,
- hardware,
- firmware components,
- ICT systems, and
- security parameters
are implemented in a controlled, secure, and fully traceable manner, preserving availability, authenticity, integrity, and confidentiality of data.
These procedures form part of the ICT change management obligations under Article 9(4)(e) DORA and must reflect a risk-based, independently governed, and auditable change lifecycle.
Mandatory Elements of the ICT Change Management Procedures
Verification of ICT Security Requirements
The procedure must include a mandatory assessment that confirms:
- ICT security requirements have been fully met before approving or deploying any change.
This includes ensuring compliance with secure configuration baselines, access-control requirements, encryption standards, network-security controls, and other obligations defined under DORA and the RTS.
Independence of Key Functions
The procedures must ensure functional separation between:
- the function approving changes, and
- the function requesting or implementing changes.
This safeguards against conflicts of interest and aligns with the three-lines-of-defence model required under Article 6(4) DORA.
Roles and Responsibilities Across the Change Lifecycle
The procedure must contain a clear, documented allocation of roles and responsibilities covering the complete change lifecycle:
- Specification and planning of changes
- Design of an adequate transition, including interdependencies, rollback plans, and scheduling
- Testing and controlled finalisation of changes (aligned with Article 16 RTS RMF testing requirements)
- Quality assurance, ensuring correctness, completeness, and compliance with internal controls
These responsibilities must be formally assigned, documented, and embedded into operational workflows and governance structures.
Documentation and Communication of Change Details
The procedure must require each change to be fully documented and its details communicated to all relevant parties. Documentation must include:
- Purpose and scope of the change
- Timeline and deployment schedule
- Expected outcomes, including functional and non-functional results
This documentation forms part of the audit trail and must be stored and retrievable.
Fall-Back Procedures and Responsibilities
The change management procedures must include:
- defined fallback and rollback procedures,
- responsibilities for activating these measures, and
- protocols for aborting or recovering from unsuccessful changes.
These procedures are necessary to avoid prolonged disruptions and ensure continuity.
Emergency Change Management Controls
The procedures must include dedicated, controlled mechanisms for emergency changes, ensuring that:
- emergency changes remain secure,
- risks are mitigated,
- deviations from the standard process are justified and documented, and
- changes are authorized at an appropriate level under time-critical circumstances.
Post-Implementation Documentation and Re-Approval of Emergency Changes
After implementation, emergency changes must be:
- documented,
- re-evaluated,
- assessed, and
- formally approved retroactively.
This includes processing workarounds, hotfixes, and patches deployed under emergency procedures.
Impact Assessment on Existing ICT Security Measures
The procedure must mandate an assessment of:
- how each change affects existing ICT security controls, and
- whether additional or compensating measures are required.
This ensures that changes do not degrade digital operational resilience or introduce new vulnerabilities.
Additional Requirements for CCPs and CSDs
Under Article 17(2), after significant changes, CCPs and CSDs must conduct stringent testing under stressed conditions.
For Central Counterparties (CCPs)
Testing must involve, as appropriate:
- (a) clearing members and clients
- (b) interoperable CCPs
- (c) other interested parties
For Central Securities Depositories (CSDs)
Testing must involve, as appropriate:
- (a) users
- (b) critical utilities and critical service providers
- (c) other CSDs
- (d) other market infrastructures
- (e) institutions with identified interdependencies
These enhanced requirements ensure systemic stability and alignment with the broader market infrastructure ecosystem.