ICT risk management is the preventive and preparatory discipline that identifies assets, dependencies, threats, and controls before disruption occurs. Incident management begins when an event happens and focuses on detection, reporting, coordination, and recovery. Together they form a resilience loop, but they solve different problems at different stages.
Why DORA Separates Prevention From Response
Under DORA, ICT risk management is about anticipating disruption: mapping ICT assets, dependencies, vulnerabilities, third-party reliance, and control gaps before an event occurs. Incident management is activated after an event and focuses on triage, classification, coordination, regulatory reporting, and restoration. The practical difference is timing, objective, and evidence: one reduces the likelihood and impact of disruption, the other limits damage once disruption is underway.
That separation matters because DORA expects firms to prove both that they know where exposure lives and that they can react in a disciplined way when controls fail. For the regulatory backdrop, see EU Digital Operational Resilience Act (DORA) and the official NIS2 Directive, both of which reinforce that resilience is not just recovery, but continuous control over ICT exposure.
Where firms struggle is treating incident handling as the whole resilience programme. That misses dependency mapping, control ownership, resilience testing, and remediation tracking, which belong in risk management. It also misses the fact that incident response depends on prior preparation such as logging, escalation paths, and tested runbooks. NHIMG’s Ultimate Guide to NHIs is useful here because it shows how exposed credentials, weak rotation, and poor visibility become upstream risk conditions before they become incidents.
How the Two Disciplines Work Together in Practice
ICT risk management is continuous and structural. It should identify critical systems, classify important dependencies, test controls, and decide what residual risk the business is willing to carry. Incident management is operational and event-driven. It detects anomalies, coordinates technical and business response, captures regulatory facts, and drives recovery to a stable state.
The cleanest way to think about the relationship is that risk management sets the defensive baseline, while incident management proves whether the baseline holds under pressure. Strong risk management reduces the number and severity of incidents; strong incident management limits the blast radius when prevention fails. DORA expects both because resilience depends on preventive design and response capability, not one or the other.
For practitioners, the distinction becomes visible in artefacts. Risk management produces inventories, dependency maps, control assessments, testing results, and remediation plans. Incident management produces timelines, severity decisions, notifications, containment actions, root-cause findings, and recovery evidence. If the same team cannot point to both kinds of outputs, the organisation is usually underinvesting in one side of the resilience loop.
What Practitioners Should Look For in a DORA Programme
Well-run programmes keep the two functions linked but not merged. Risk owners should understand which weaknesses are systemic, which third parties matter, and which controls must be improved before the next disruption. Incident handlers should have the authority to triage quickly, escalate cleanly, and preserve evidence while restoring service. The two groups need a shared view of critical assets, but they should not share the same success metrics.
Decision rule: if the question is “what could fail, how likely is it, and what should be improved before failure”, you are in ICT risk management. If the question is “what happened, who needs to know, what must be contained, and how do we recover”, you are in incident management.
What to verify: confirm that incidents feed back into risk registers, control improvements, and testing priorities. Without that loop, an organisation may respond well to each event while repeatedly leaving the underlying exposure unchanged. For an operational lens on recurring exposure and weak remediation discipline, NHIMG’s 2025 State of NHIs and Secrets in Cybersecurity shows how visibility, rotation, and offboarding gaps turn into repeatable compromise conditions.
Practitioner takeaway: DORA is not asking for one universal “resilience process”, it is asking for two linked capabilities: one that reduces ICT exposure before disruption and one that demonstrates disciplined action after disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while DORA and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT risk management — ICT Risk Management | The question directly contrasts DORA's preventive risk discipline with incident handling. |
| Incident management and reporting — Incident Management and Reporting | The question asks how incident management differs once an event occurs under DORA. | |
| Recommendation — Map ICT assets, dependencies, and controls before disruption to reduce operational exposure. Define detection, escalation, reporting, containment, and recovery steps for ICT incidents. | ||
| NIS2 | Incident handling and reporting — Incident Handling and Reporting | NIS2 reinforces the operational difference between prevention and post-event response. |
| Recommendation — Establish reporting, coordination, and recovery workflows for significant cyber incidents. | ||
| NIST CSF 2.0 | RS.RP — Response Plan Execution | Incident management depends on executing a prepared response plan under pressure. |
| ID.RA — Risk Assessment | ICT risk management is the structured assessment of assets, threats, and control gaps. | |
| Recommendation — Test and rehearse response procedures so teams can contain and recover from incidents quickly. Assess assets, dependencies, and threats to prioritise the highest ICT risks first. | ||
Related resources from NHI Mgmt Group
- Who is accountable for ICT risk management under DORA?
- What is the difference between a Critical Infrastructure Risk Management Program and enhanced cyber security obligations under SOCI?
- What is the difference between vendor risk management and identity governance?
- What is the difference between static vulnerability scanning and runtime risk management?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
