DORA ICT Risk Management: The Five Pillars Your IT Function Needs to Cover

1. ICT Risk Management

This is the foundation the other four pillars sit on. DORA requires a documented ICT risk management framework that identifies, assesses, and mitigates risk across your systems, not as an annual exercise, but as an ongoing function with clear ownership at management body level.

In practice, this means your asset inventory, your network segmentation model, and your risk register need to actually connect to each other. A firewall policy review or a network hardening assessment is not just a technical exercise anymore. It is an input to a risk framework that your board is accountable for.

2. ICT-Related Incident Management, Classification, and Reporting

DORA sets out specific criteria for classifying ICT incidents by severity, and mandates reporting timelines to regulators for major incidents. This is where a lot of IT functions discover a gap: they have monitoring and alerting, but they do not have a defined, tested process for classifying an incident's severity and escalating it against a regulatory clock.

The practical requirement is a runbook that ties technical detection (a SIEM alert, an IDS trigger, an unusual authentication pattern in your NAC logs) to a business classification decision, made quickly enough to meet reporting deadlines. This needs to be tested before you need it, not designed during the incident itself.

3. Digital Operational Resilience Testing

DORA requires regular testing of your ICT systems, including basic testing (vulnerability assessments, scenario-based testing) for most entities, and Threat-Led Penetration Testing (TLPT) for entities designated as significant. This is broader than a yearly pen test box-check. It includes testing whether your resilience actually holds under realistic conditions, such as a segmentation boundary failing, a critical vendor's API going dark, or a failover path that has never actually been exercised.

For network and infrastructure teams, this is where design decisions from years ago get tested against present-day assumptions: does that redundant link actually reroute traffic the way the diagram says it does, and does anyone have evidence it does?

4. ICT Third-Party Risk Management

This is arguably where DORA changes the most for financial entities. It requires a register of all ICT third-party providers, contractual clauses covering exit strategies and audit rights, and ongoing risk assessment of critical providers, not just at onboarding, but throughout the relationship.

For most organizations, this means the security team needs visibility into contracts that used to live purely in procurement, and procurement needs technical input on what “critical” actually means for a given vendor. A cloud provider hosting your core banking platform and a SaaS tool used by three people in marketing are not the same risk category, and DORA expects you to be able to demonstrate that distinction.

5. Information and Intelligence Sharing

The fifth pillar is more voluntary in nature: DORA encourages financial entities to participate in threat intelligence sharing arrangements with peers. In practice, this is the pillar most organizations treat as optional, and it often is, at least initially. But it is worth building the internal process for consuming and acting on shared threat intelligence even before formal participation, since the other four pillars work better when informed by what is actually being seen across the sector.

Where this actually lands

None of these five pillars are purely a compliance or purely a technical exercise. Each one requires someone who can read the regulatory text and translate it into a control that a network engineer, a SOC analyst, or a vendor manager can actually implement and evidence. That translation step, more than the regulation itself, is usually where organizations get stuck.