Mapping ICT risk under DORA is often presented as a documentation exercise. In practice it reveals something less comfortable: the real structure of an organisation's critical dependencies, with its blind spots, its hidden interdependency chains, and its continuity plans that would not survive examination. In 2025 the EBA published its first report on cloud provider concentration in European financial services. The finding was unambiguous: three hyperscalers concentrate more than 65 percent of the critical cloud services deployed by EU financial entities. DORA anticipated this. Article 30.4 explicitly requires entities to consider ICT concentration risk in their third-party strategy, at entity level and at sector level.
What Article 30.4 actually requires
Most DORA compliance work concentrated on Article 30.2: contractual requirements with critical ICT providers (termination clauses, audit rights, service levels). Those are tangible, negotiable, and covered by standardised review grids.
Article 30.4 is different, and less tooled. It requires assessing whether ICT arrangements create concentration risk, across two dimensions: can the entity replace a provider within reasonable time if needed? And is substitution possible at sector level, or would that provider's failure hit many entities at once?
The second question moves responsibility beyond individual strategy. Your DORA compliance is not assessed only by asking whether you have an exit plan. It is assessed by asking whether your sector has one. That is a structural difference from NIS2 or GDPR, which stay entity-centred.
Three invisible dimensions of ICT concentration
Horizontal concentration. One provider used across distinct services: storage, compute, AI, security, CDN. Dependency on each individual service looks small. Aggregate dependency on a single provider across the whole stack is structural. A major incident there does not affect one service. It affects every function it supports.
Vertical concentration. The critical path of a service passes through the same provider at several levels. A common case: your business application is hosted by an ISV, and that ISV hosts its own infrastructure with the same hyperscaler you use. Apparent redundancy hides a shared upstream dependency.
Sector concentration. Your direct competitors use the same critical ICT providers. An incident at that hyperscaler does not isolate you. It isolates the whole sector at once. Systemic effects then amplify: simultaneous failure across many entities saturates the provider's support teams, slows resolution, and creates competition for remediation resources.
What honest mapping consistently reveals
First, the number of critical dependencies is generally two to three times the initial estimate. DORA's definition of critical, systems whose interruption or degradation would significantly affect business functions, is broader than the one IT teams use intuitively. Monitoring systems, GRC tools and secure communication platforms fall in scope more often than expected.
Second, indirect dependencies are systematically under-documented. Your third-party register lists direct providers. It does not document your providers' providers. DORA nonetheless requires visibility across the full chain for critical functions. The gap between what you think you control and what you actually control is one of the most frequent findings in early formal assessments.
Third, continuity plans do not cover provider failure. Most business continuity plans were designed for internal failures: hardware, network, human error. A prolonged failure of the primary cloud provider, or a regulatory decision excluding a hyperscaler from the European market, is rarely documented, rarely tested, and rarely budgeted.
The exit plan nobody wants to write
DORA Article 28.8 requires documented exit strategies for critical or important ICT service providers. It may be the most systematically deferred article in the regulation.
Documenting an exit plan for a hyperscaler means answering questions few organisations want to ask formally. How long would it take to migrate critical workloads to another provider? What would that migration cost? Do you have the in-house skills to execute it without that provider's support? What is the minimum time to reach equivalent service elsewhere?
Honest answers are part of the concentration risk assessment. An exit plan concluding that migration would take eighteen to twenty-four months is not necessarily non-compliant. It is, however, documentation of a structural dependency that your continuity plan must carry as a working assumption.
Preparing your concentration declaration
For financial entities under supervision, the ICT arrangements information register, expected in the standardised EBA format, includes a section on concentration risk. Its quality is directly assessable by the supervisor without a prior interview.
A robust declaration rests on three deliverables: a full inventory of ICT providers by critical function, with criticality level and nature of the dependency (direct or indirect); the horizontal and vertical concentration matrix by provider; and documented exit plans, with estimated timelines and trigger conditions.
Presidio structures those three deliverables in a dedicated module aligned with the EBA register format and connected to the DORA control library. See Presidio →
Conclusion
DORA Article 30.4 is not a documentation exercise. It is an invitation to look squarely at the real structure of your dependencies, and to decide, knowingly, what level of concentration is acceptable and under what conditions.
Entities that handle this with the most maturity share an approach: they treat ICT dependency mapping as a strategic decision tool, not a regulatory box. The difference shows in the quality of the exit plan, and in the ability to answer the question your supervisor will eventually ask: if this provider disappeared tomorrow, how long until your business is fully operational again?
In your organisation, do you have a documented answer to that question, or only an intuition?
Read next: TPRM 2026: seven pitfalls when mapping third parties.