What is the DORA regulation for Digital infrastructure (CDN)?
DORA requires financial institutions to treat the CDN as part of their ICT risk environment when it supports important or critical services. You need to understand the dependency, manage the provider and configuration risks, document responsibilities, test resilience, and prove you can keep the service available when the CDN has a problem.
The CDN provider is responsible for its own platform, but that does not transfer your DORA obligations to the vendor. You still own how the CDN is configured, how it affects critical services, what evidence you keep, and how you respond, recover, or switch traffic when that dependency fails.
What DORA Requires From Financial Institutions and Their Digital Infrastructure Providers
If every request to your online banking application passes through a CDN, the CDN is part of that system. Your origin servers can be healthy while a CDN outage, certificate problem, routing error, bad WAF rule, or DNS failure makes the service unavailable.
Treat the CDN as Part of the Delivery Path
That is why dora regulation requirements around ICT risk management matter to CDN architecture. Your dora ict risk process needs to cover the real delivery path, not just infrastructure owned directly by your company.
DORA requires financial entities to maintain an ICT risk-management framework, monitor and control the security and functioning of ICT systems, use appropriate security procedures, detect anomalous activity, maintain response and recovery capabilities, and test digital operational resilience. It also requires appropriate documented policies for patches and updates.
Separate Provider Duties From Your Configuration Duties
The CDN provider may be responsible for vulnerabilities in its own edge platform or network. Your team still owns:
- Origin exposure, network security gateway policies, and firewall allowlists
- WAF exceptions and custom security rules
- TLS settings and certificate workflows
- API tokens and administrative access
- Edge functions and the code they execute
- Cache policies and request-routing behavior
- DNS records and failover controls
- Configuration monitoring and change ownership
So vulnerability remediation cannot stop at "the CDN vendor patches its servers." If your configuration exposes the origin or an edge function contains vulnerable code, that remains part of the risk you have to manage.
Plan for Incidents Across the CDN Boundary
The same principle applies to incidents. If the CDN reports a service problem affecting your customer portal, your process needs to detect the impact, classify it, escalate it, recover from it, and determine whether DORA incident-reporting requirements are triggered.
Where CDN Providers Fit Into DORA's ICT Third-Party Risk Framework
Article 28 requires financial entities to manage ICT third-party risk as part of overall ICT risk. They must also maintain a register of information covering contractual arrangements for ICT services and perform risk assessment and due diligence before entering relevant arrangements.
Classify the Dependency by Business Impact
For a CDN, I would start with one simple question:
What stops working if this provider disappears?
Classify the dependency by tracing the real business impact of losing it:
- If only image acceleration disappears, the operational consequence may be limited
- If customers cannot authenticate, the CDN is affecting access to the financial service itself
- If mobile APIs or payment endpoints become unreachable, availability and continuity are directly affected
- If WAF and DDoS controls disappear with the CDN, the failure also changes the application's security exposure
- If logs and traffic evidence become unavailable, incident detection and regulatory assessment may be delayed
Separate Critical Functions From CTPP Designation
DORA uses the concept of a critical or important function. You need to determine whether disruption to the function supported by the ICT service would materially impair your financial performance, continuity of services, or ability to comply with regulatory obligations.
Keep two classifications separate when documenting the dependency:
- Your institution decides whether the business function supported by the CDN is critical or important
- The European Supervisory Authorities separately decide whether the provider is a critical ICT third-party provider at Union level
- Your own risk-management duties apply even when the provider is not designated as a CTPP
- A CTPP designation adds provider oversight, but it does not transfer your institution's operational responsibility
A provider does not automatically become directly regulated by the ESAs because one financial institution considers its CDN service critical. Under DORA's oversight framework, the ESAs designate ICT third-party providers considered critical at the Union financial-sector level, publish the CTPP list, and oversee those designated providers. The EBA states that the list is published and updated annually under Article 31(8).
Your financial entity must manage the CDN dependency whether or not the provider is a designated CTPP. If the provider is designated, it also becomes subject to DORA's oversight framework, including Lead Overseer powers to request information, investigate, inspect, and issue recommendations.
That is the cleanest way to think about dora compliance here: your compliance cannot be outsourced to the CDN.
The Specific DORA Obligations That Apply When a CDN Is a Critical Dependency
Once a CDN supports a critical or important function, you need stronger evidence that the dependency is understood and controlled.
Assess Due Diligence and Concentration Risk
Before entering an ICT arrangement supporting a critical or important function, DORA requires the financial entity to assess relevant risks, consider whether the provider is suitable, examine concentration risk, and consider the information-security standards used by the provider.
For a CDN, translate due diligence into technical questions:
- Where does traffic terminate and where is data processed?
- Which services are subcontracted?
- What happens during a regional outage?
- Can you retrieve complete logs during an incident?
- How are administrative changes authenticated and reviewed?
- What happens if the provider suspends the account?
DORA requires financial entities to consider whether a provider supporting critical or important functions is difficult to substitute and whether multiple important arrangements depend on the same provider or closely connected providers.
You can have applications in three cloud regions, redundant origin servers, and separate internal teams, but still place every public service behind one CDN account. The architecture looks distributed until the common edge layer fails.
A multi-CDN strategy can help reduce that kind of concentration risk when the architecture and business impact justify it. DORA does not say every financial institution must deploy two CDNs. The requirement is to assess concentration risk and make a defensible resilience decision.
Lock Contractual and Exit Requirements Into the Operating Model
Article 30 requires written ICT contracts to clearly allocate rights and obligations and include service descriptions, relevant service and data-processing locations, service levels, data protections, incident assistance, cooperation with authorities, and termination provisions. Contracts supporting critical or important functions require additional detail, including precise service levels, reporting obligations for developments that could materially affect delivery, tested contingency plans, security measures, and appropriate access, inspection, and audit rights.
For ICT services supporting critical or important functions, DORA requires documented exit strategies and plans that are sufficiently tested and periodically reviewed. You must be able to leave the arrangement without disrupting business activities, undermining regulatory compliance, or damaging service continuity and quality.
A credible exit plan should answer practical migration questions:
- Can you change DNS safely?
- Can certificates be moved without an outage?
- Can WAF policies be recreated on another provider?
- Are edge functions portable?
- Will the origin accept traffic from the alternate path?
- Can you migrate without exposing the origin to DDoS traffic?
If nobody has tested those assumptions, you have an exit document, not necessarily an exit capability.
Test the Failure Modes You Actually Depend On
DORA's resilience-testing framework includes vulnerability assessments and scans, network-security assessments, scenario-based tests, performance tests, end-to-end tests, and penetration testing. For financial entities other than microenterprises, systems and applications supporting critical or important functions are subject to appropriate testing at least yearly.
For CDN infrastructure, useful tests include:
- Origin-bypass and WAF-bypass attempts
- DNS failure and certificate-renewal failure
- Edge-configuration mistakes and API exposure
- Regional failure and full provider unavailability
- Failover to another traffic path
Make every resilience exercise produce evidence that someone can review later:
- Run failure exercises from more than one region so a local network issue is not mistaken for a provider-wide incident
- Include partial degradation as well as complete outages, because a CDN can remain technically available while real users still fail
- Record how long detection, escalation, traffic switching, recovery, and validation take
- Verify that WAF, DDoS, TLS, and logging controls remain consistent on the alternate path
- Retain the logs, approvals, test results, and lessons that show how the next exercise will improve
DORA is not prescribing one identical CDN test for every company. It is requiring you to prove that the resilience claims behind your architecture are more than assumptions.
What Financial Institutions Need to Verify About Their CDN Setup Before a DORA Audit
Before a DORA audit or supervisory review, I would trace one critical customer service from the user's device all the way to the application.
You should be able to show the complete delivery path:
- Where DNS resolves and TLS terminates
- Which CDN handles traffic
- Where WAF and DDoS controls run
- Which origins receive requests
- What happens during failure
- Who owns each control
Bring Evidence, Not Just Assurances
Then work through the evidence:
The weak answer is, "Our CDN is a major vendor and has good certifications."
Certifications can support due diligence, but an audit-ready evidence set should also include:
- A current service map showing how the CDN connects to DNS, TLS, WAF, APIs, origins, and recovery paths
- Configuration records and change history for the controls your teams manage
- Monitoring and incident records showing how provider events reach the right owners
- Test results for outage, bypass, recovery, and provider-exit scenarios
- Contractual evidence covering service levels, assistance, audit rights, termination, and data handling
Connect Ownership Across Teams
Pay particular attention to controls that sit between teams:
- Security may manage the WAF
- Infrastructure may own DNS
- Developers may own edge code
- Procurement may own the contract
- Compliance may own the DORA register
Your audit evidence should connect the pieces. Show the dependency, owner, risk assessment, security controls, monitoring, testing, contractual protection, recovery procedure, and exit path as one operating model.
Also verify that the architecture matches the paperwork. If your assessment says the CDN is non-critical but removing it makes every customer-facing service unreachable, that classification deserves another look. If your exit plan says traffic can move elsewhere, test whether DNS, certificates, security policies, origins, and observability actually work there.
During an audit, the strongest evidence is operational rather than assumptions written only into policy documents: you can explain the CDN dependency, show how the dora ict risk is controlled, produce the relevant test and incident records, and demonstrate that critical financial services have a realistic recovery or exit path when the edge layer fails.