DORA: Managing ICT Risk on a Changing External Perimeter

A new public host, a cloud endpoint or a remote access service can appear between two scheduled inventories. If an organization does not notice that change, it cannot establish the owner of the asset in time, assess the risk, or check whether exposing the service was authorized. The actual external perimeter then drifts away from the register, and management and auditors are left without end-to-end evidence of control.

Since 17 January 2025, financial entities within the scope of DORA have had to identify sources of ICT risk on a continuous basis and to maintain a documented framework for managing it. If an external asset belongs to the organization's ICT assets or supports its functions, it has to enter the cycle of identification, assessment and control (DORA, Articles 6 and 8).

Why a static list is not enough

DORA requires entities to identify information assets and ICT assets, including network resources and hardware equipment at remote sites, and to map critical assets, their configurations and their interdependencies. Registers have to be updated periodically and upon every major change (DORA, Article 8(4)).

The Delegated Regulation requires ICT asset records to include, among other things, the identifier, the location, the owner, the business functions supported, the interdependencies, and information on accessibility from external networks, including the internet (Regulation (EU) 2024/1774, Article 4).

A list of addresses therefore answers only one question: what was visible on the day of the check. It does not show when an asset became reachable from outside, whether it is recorded in the internal register, which function depends on it, who is accountable for the risk, and whether the change went through the established procedure.

External perimeter monitoring can detect a new asset or a change in exposure. Only an internal process can determine the owner, the criticality, the acceptability of the risk and the next action.

Step 1. Detect the changes

DORA requires entities to identify sources of ICT risk on a continuous basis and to assess cyber threats and vulnerabilities relevant to their functions and assets. A risk assessment is also required upon each major change to the infrastructure, to the processes or to the procedures affecting ICT-supported business functions and assets (DORA, Articles 8(2) and 8(3)).

For the external perimeter, this means comparing successive states on a regular basis. The verifiable outcome is not a checkbox saying that scanning is switched on, but a record of which asset and which externally reachable services were found, and when.

At the same time, DORA does not declare every change to a public host a major one. The materiality criteria, the review route and the authority of the person taking the decision are for the organization to define.

Events can be sorted into three queues:

1. a known asset whose external accessibility has changed;
2. a new asset with an established owner and purpose;
3. a new asset whose owner or purpose is unknown.

This is not a classification taken from DORA; it is a way to make the control verifiable. For every event, the time of detection, the result of the match against the register and the decision taken are all visible.

Step 2. Link the asset to a business function

An IP address or a domain name on its own does not produce a risk assessment. DORA requires entities to classify ICT-supported business functions, information assets and ICT assets, and to document their roles and dependencies. Entities also have to identify the processes that depend on ICT third-party service providers, and the links with providers supporting critical or important functions (DORA, Articles 8(1) and 8(5)).

A discovered cloud endpoint has to be matched to an owner, a system and the function it supports. Without that, there is no way to set the urgency of the review or the applicable requirements for availability, integrity and confidentiality.

Technical tooling can suggest a link through a certificate, DNS records, a cloud account or other signals. Confirming the owner and the business function remains a task for the process. A practical indicator for an IT leader is the share of discovered external assets that have a confirmed owner and a link to the internal register. DORA sets no ready-made target for it.

Step 3. Route the event into change management

The Delegated Regulation sets out the requirements for network security management and for changes to ICT systems: changes have to be recorded, assessed, approved, implemented and verified in a controlled manner (Regulation (EU) 2024/1774, Articles 12 and 16).

Every confirmed change in external exposure should therefore either have a linked record of an authorized change, or create a task to investigate the deviation.

Three outcomes are possible:

• the change was authorized and is reflected in the register;
• the change was authorized, but the documentation has not been updated;
• the change is not confirmed and calls for restricting access or opening an investigation.

Step 4. Keep the evidence of control

DORA requires the ICT risk management framework to be documented and reviewed at least once a year, as well as after major ICT-related incidents, supervisory instructions or findings from testing and audits. Entities have to audit the framework internally and to follow up on the remediation of the findings (DORA, Articles 6(5)-6(8)).

For the external perimeter, what helps is not only the current list, but the chain of records:

detection → owner identification → link to the asset and the function → assessment → decision → change of control → verification of the result

The monitoring log shows what appeared or disappeared, when it was noticed and what became visible after the fix. The asset register, the change request, the risk assessment and the approval by the accountable person cover the process side.

An external observation tool does not prove that management approved the level of risk as acceptable. DORA places responsibility for the ICT risk management arrangements, the allocation of roles, the continuity policy and the audit on the management body (DORA, Article 5).

Where external perimeter monitoring does not help

The rules reviewed here do not require buying a separate product for external attack surface management. What is required is an outcome: current identification of assets and sources of risk, control of changes, documented decisions, and the ability to verify that the framework works.

Monitoring covers the observable part: it finds publicly reachable assets, records changes, and lets you check the exposure after an action has been taken. It does not replace:

• the classification of critical and important functions;
• the assignment of asset owners;
• the criteria for a major change;
• the acceptance or the rejection of risk;
• the approval of changes;
• the contractual management of ICT third-party providers;
• internal audit and the follow-up of corrective measures.

Instead of yet another list of domains, an IT leader needs an end-to-end report for the period: which changes to the external perimeter were detected, which assets and functions they were matched to, who took the decision, and which document confirms the closure of each deviation.

From requirement to verifiable evidence

For each requirement below: the verifiable action, what monitoring provides on its own, and what only the process can provide.

Identify sources of ICT risk

• Reference — DORA, Article 8(2)
• Verifiable action — compare successive states of the perimeter and record the changes
• What monitoring provides — the asset and the time of detection
• What the process provides — the review queue, the accountable person and the risk decision

Maintain the asset register

• Reference — DORA, Article 8(4); 2024/1774, Article 4
• Verifiable action — match the external asset to a record in the register
• What monitoring provides — technical signals of the link and of the discrepancies
• What the process provides — confirmation of the owner, the purpose and the function

Assess major changes

• Reference — DORA, Article 8(3)
• Verifiable action — pass the relevant events on to risk assessment
• What monitoring provides — data on the new exposure
• What the process provides — the materiality criteria and the decision itself

Control changes

• Reference — 2024/1774, Articles 12 and 16
• Verifiable action — link the exposure to a change request or to a deviation
• What monitoring provides — reconciliation of the actual state with the recorded one
• What the process provides — assessment, testing and approval

Audit ICT risk management

• Reference — DORA, Articles 6(5)-6(8)
• Verifiable action — keep the chain from detection to verification
• What monitoring provides — the history of observations
• What the process provides — management decisions, audit and follow-up of the remediation