DORA Article 9(4) requires financial entities to document an information security policy, manage networks and infrastructure with the ability to segment or sever connections, limit access to what is needed, use strong authentication and key protection, run risk-based change management for all ICT changes, and keep documented patch and update policies.
What the six points say
Article 9(4) lists these within the ICT risk management framework:
- (a) Information security policy that defines rules to protect the availability, authenticity, integrity and confidentiality of data, information assets and ICT assets.
- (b) Network and infrastructure management using appropriate techniques and, following a risk based approach, possibly automated mechanisms to isolate affected assets during cyber-attacks. Network connections must be designed so they can be instantaneously severed or segmented to prevent contagion.
- (c) Access limits: physical or logical access restricted to what is required for legitimate and approved functions, with policies and controls for access rights administration.
- (d) Strong authentication based on relevant standards and dedicated control systems, with protection of cryptographic keys and encryption based on data classification and risk assessment.
- (e) Change management: documented policies, procedures and controls for changes to software, hardware, firmware and security parameters, based on risk assessment, so that all changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner. The process must be approved by appropriate management levels.
- (f) Patch and update policies: appropriate, comprehensive and documented.
Change management in software terms
The article reads like a description of a controlled delivery pipeline. For each change type, show evidence of:
- Record: a ticket or pull request referencing the change.
- Test: CI results attached.
- Assess: a review that considers risk, with extra scrutiny for security parameters and critical systems.
- Approve: an approver who is not the author, with management approval of the process itself.
- Implement: a controlled deploy with a rollback path.
- Verify: post-deploy checks.
Emergency changes need their own documented route with after-the-fact review.
Patch policy
DORA says only that the policy must be "appropriate and comprehensive" and documented. Write severity based target windows, testing steps, an owner, and an exception process. Article 8(7) separately asks for yearly risk assessment of legacy systems that cannot be patched.
Segmentation and isolation
The requirement to sever or segment connections "instantaneously" is concrete. Check you can isolate a compromised segment, cut a third-party link, or disable an integration quickly. Test it, and record the test, since Article 11 asks for yearly testing of response and recovery plans.
Authentication and keys
Strong authentication, multi-factor where appropriate to the risk, and protected cryptographic keys with a key management process. Keep a record of who can administer keys and how access is reviewed.
Safeguard's policies, gates and guardrails can enforce several change checks in the pipeline, and its dependency scanning supports patch prioritisation. Autonomous remediation with fix PRs is off by default and every category starts on Manual.
Quick check
Does DORA say how fast to patch?
No. It requires a documented, appropriate and comprehensive patch and update policy, leaving timing to your risk assessment.
Does change management cover configuration and firmware too?
Yes. Article 9(4)(e) covers software, hardware, firmware components, systems and security parameters.
Sources
Last reviewed: 19 October 2026.
