ESA Publishes Guide on ICT CTPPs Oversight

If you’ve ever said, “Our cloud provider is rock-solid,” the European Supervisory Authorities just replied,
“Coolshow us your homework.” That’s the vibe behind the ESAs’ newly published guide on how they’ll oversee
critical ICT third-party providers (CTPPs) under the EU’s Digital Operational Resilience Act (DORA).

Translation: the biggest tech providers that power core financial servicesthink cloud, data, networks, and
certain “if this breaks, everything breaks” platformsare no longer just vendors. In the EU, some of them are now
officially “critical,” and the ESAs have laid out how oversight will actually work in practice.

First, a quick decoder ring (so we’re all speaking human)

• ESAs: the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA), acting together on DORA oversight.
• ICT: information and communication technology (everything from infrastructure to software and data services that keep finance running).
• CTPP: a third-party ICT provider designated as “critical” to the EU financial sector.
• Oversight: the ESAs’ direct supervisory-style engagement with those critical providersseparate from (and complementary to) each financial institution’s own vendor risk management.

Why this guide matters (even if you’re not in the EU)

DORA is designed to strengthen resilience across the financial sector, and one of its boldest moves is the
EU-level oversight framework for critical ICT providers. The guide matters because it answers the
“Okay, but how will this work in real life?” question.

For global tech providers (including many headquartered or heavily operated in the U.S.), this is also a major
signal: if you serve EU-regulated financial entities at scale, your governance, incident handling, testing,
subcontractor controls, and operational resilience story may be reviewed in a structured, recurring wayby a
“Lead Overseer” supported by joint teams.

Who becomes a “critical” ICT CTPP?

The ESAs’ guide reinforces what DORA sets out: criticality is about systemic impact and concentration risk, not
whether a vendor has a sleek logo or a great sales deck.

The big four criticality “buckets”

1. Systemic impact if the provider suffers a major operational failure (stability, continuity, quality of financial services).
2. Systemic importance of the financial entities relying on the provider.
3. Reliance on the provider for critical or important functions (especially where many firms depend on the same provider).
4. Substitutability (how hard it would be to switch, migrate, or replace services without serious pain).

Notably, the designation process draws heavily on “register of information” data reported by financial entities to
competent authorities (national regulators), then shared in aggregated form. In other words: the EU is using
the sector’s own reporting to map dependency and concentration.

The oversight model in plain English: a repeatable cycle

The guide describes oversight as a set of recurring activities that flow together. If you like simple mental models,
think of it as: designate → plan → examine → recommend → follow up → repeat.

1) Designation (and the “you’ve got six weeks to respond” moment)

Each year, the ESAs publish the list of designated CTPPs based on registers of information and other available data.
Providers are notified of the assessment outcome and can submit a reasoned statement within a defined window.

There’s also an “opt-in” pathway: a provider not on the list can ask to be assessed for designation as critical.
That’s counterintuitive until you remember one thing: some providers prefer a clear, harmonized oversight lane
over a messy patchwork of expectations across customers and jurisdictions. Yes, some companies actually like
clarity. Wild.

2) Risk assessment & planning (your “oversight plan” is basically a syllabus)

Oversight intensity isn’t meant to be one-size-fits-all. The overseers conduct an annual risk assessment of each
CTPP to estimate its risk profile and set priorities. The result is an oversight plan (annual and multi-annual),
communicated to each CTPP.

A practical takeaway: if you’re a designated provider, you should expect “themes” and focus areas that reflect
what the overseers see as the biggest risksconcentration, subcontracting chains, resilience of critical services,
major incident patterns, and the maturity of governance and controls.

3) Examinations (where the questions stop being hypothetical)

Examinations are how the ESAs (through the Lead Overseer) assess the risks a CTPP may pose to EU financial entities.
This isn’t limited to one mechanism. The guide describes multiple tools and modes, including:

• Ongoing monitoring (regular engagement and information analysis)
• Requests for information (targeted asks without launching a full investigation)
• General investigations (deeper dives, broader evidence gathering)
• Inspections (including rights to request records, data, and relevant documentation)

If you’ve lived through audits before, this will sound familiarexcept the audience is cross-sector EU oversight,
and the aim is resilience of the services that underpin financial stability.

4) Recommendations & follow-ups (aka “fix it, and prove you fixed it”)

When deficiencies are identified, overseers can issue recommendations focused on specific areas of assessment.
Follow-up happens through ongoing monitoring and reporting on actions taken or remedies implemented.

Another key point: the guide explains that relevant insights, including recommendations and follow-ups, can be
shared with national competent authorities supervising the financial entities that rely on that CTPP. So while
oversight targets the provider, the ripple effects can reach the provider’s customers’ supervisors too.

Who’s in charge: Lead Overseer, JETs, and the governance stack

The guide outlines a governance structure designed to keep oversight consistent across banking, securities, and insurance.
Oversight is carried out by a Lead Overseer (one of the ESAs) supported by Joint Examination Teams (JETs)
that can include staff from national competent authorities.

Above the operational layer, the ESAs use cross-ESA governance bodies (including the Joint Committee and an Oversight Forum)
to coordinate, promote consistent approaches, and steer certain outcomes like designation and collective assessments.

The “why” here is important: this framework is designed to reduce duplication and avoid a scenario where a critical provider
gets pulled in 27 directions at once by separate national supervisorswhile still ensuring supervisors have the information
needed to oversee financial entities’ vendor dependencies.

What overseers will really care about (hint: it’s not your marketing site uptime)

Oversight is about whether a CTPP has comprehensive, sound, and effective rules, procedures, mechanisms, and arrangements
to manage ICT riskespecially where failures could cascade through the financial sector.

Expect scrutiny around areas like:

• Governance and accountability (clear ownership, escalation paths, decision-making discipline)
• Risk management framework (how risks are identified, measured, mitigated, and monitored)
• Operational resilience (continuity planning, redundancy, recovery objectives, testing results)
• Incident management (detection, response, communications, root-cause analysis, lessons learned)
• Change and configuration control (because “we deployed on Friday night” is rarely a love story)
• Third- and fourth-party risk (subcontractors, dependencies, chain-of-outsourcing visibility)
• Security controls (access, identity, monitoring, vulnerability management, encryption practices)
• Data management and integrity (availability, confidentiality, integrity in critical services)
• Testing and assurance (evidence that controls worknot just that a policy exists)

What CTPPs should do now: a practical playbook

If you’re a likely-designated provideror you serve many EU financial entities and want to be readythink in terms of
building an “oversight-ready” posture. That’s not the same as “passing an ISO audit.” It’s closer to: can you
demonstrate operational resilience outcomes, prove governance works under stress, and explain dependencies with confidence?

1) Build an “evidence map” before someone asks for it

The biggest time sink in oversight-style reviews is scrambling to find artifacts. Create a structured library for:
policies, standards, control testing results, incident records, resilience testing outcomes, change logs, and dependency maps.
Make it easy to show both design and operational effectiveness.

2) Get serious about dependency transparency

“We outsource some parts” won’t cut it. Expect questions like: What’s your critical service inventory?
What are the single points of failure? Which subcontractors support critical components? How do you monitor them?
What are the exit options if a key subcontractor fails?

3) Treat resilience testing like a product, not a checkbox

The providers that do well in oversight settings tend to test: recovery time objectives, failover procedures,
incident response playbooks, and crisis communicationsthen show what changed afterward. Oversight loves a good
“we learned X and improved Y” story because it signals maturity.

4) Prepare a “designated entity” communications lane

DORA expects interaction to be organized. Providers that centralize regulator engagement (without bottlenecking it)
move faster. Consider a dedicated response team that can coordinate SMEs, legal, risk, security, resilience, and operations.

What financial entities should do (because you can’t outsource responsibility)

DORA oversight of CTPPs does not replace a financial entity’s own obligations. Banks, insurers, asset managers,
payment firms, and other in-scope entities still need robust ICT third-party risk management: due diligence, contracting,
ongoing monitoring, and exit planning.

In practice, the ESAs’ oversight can become an additional input into a financial entity’s vendor risk decisionsespecially
when national supervisors receive insights about provider deficiencies or recommended remediation themes.

Three practical moves for financial entities

• Tag and track CTPPs in your vendor inventory so your monitoring, contract reviews, and contingency planning reflect the higher concentration risk.
• Align contract expectations with resilience realities (service levels, incident notification, testing participation, audit/inspection support, subcontractor transparency).
• Upgrade exit planning from “we could switch someday” to “we have a feasible, tested path for critical services.”

A readiness checklist you can actually use

Whether you’re a provider or a financial entity, these questions are a strong start:

• Can we clearly identify our critical services and the dependencies that support them?
• Do we have measurable resilience objectives (and evidence of testing against them)?
• Are incident response and communications processes proven under realistic conditions?
• Do we understand subcontractor chains for critical componentsand how we monitor them?
• Can we produce governance evidence (decisions, risk acceptance, remediation tracking) without panic?
• Do we have a credible exit strategy for critical ICT arrangements?

The U.S. angle: why American firms should pay attention

Many CTPPs are global providers, and many financial entities operate across jurisdictions. That means DORA’s oversight
approach can influence how resilience expectations are negotiated, documented, and tested worldwide.

Also, the themes aren’t alien to U.S. regulators. U.S. banking agencies have issued interagency guidance on third-party
relationships emphasizing lifecycle risk managementplanning, due diligence, contracting, ongoing monitoring, and termination.
On the cybersecurity side, frameworks like the NIST Cybersecurity Framework 2.0 help organizations structure governance and
risk outcomes in a consistent way. The details differ, but the direction is similar: stronger accountability for technology risk,
especially where concentration and dependency can amplify disruptions.

Experiences in the real world: what “CTPP oversight readiness” feels like (about )

In practice, organizations don’t experience “oversight readiness” as a single project. It shows up as a series of very specific
momentsusually triggered by a request that seems simple until it isn’t.

Experience #1: The Great Documentation Treasure Hunt. A provider gets a request for information and realizes the artifacts exist,
but not in one placeand not in one version. Security has one diagram, operations has another, and the resilience team has a third that
references a system retired two quarters ago. The fix isn’t “make more documents.” The fix is building an evidence map with clear ownership,
a single source of truth, and a routine that keeps it current. The “win” looks boring: fewer meetings, fewer contradictions, and faster responses.

Experience #2: The Dependency Graph That Ate the Week. Once you start mapping critical services, you discover the “fourth parties.”
The core platform relies on a managed service, which relies on a monitoring tool, which relies on a DNS provider, which relies on… you get the idea.
Teams often report a moment of surprise: “We didn’t realize this subcontractor is effectively part of our critical path.” Mature programs respond by
classifying dependencies, documenting criticality, and putting monitoring and contingency expectations where they belongon the most consequential links.

Experience #3: Resilience Testing Moves from Theory to Theater (in a good way). Tabletop exercises evolve into realistic simulations:
failover tests, recovery drills, communications rehearsals. The first run is rarely perfect. The real value is what happens afterward:
a better runbook, tightened access controls, improved escalation paths, and a clearer customer communication plan. Over time, organizations learn a
practical truth: the goal isn’t “never have an incident.” It’s “handle incidents without turning them into sector-wide events.”

Experience #4: Contract conversations get sharper. Financial entities often say that oversight themes make vendor negotiations more concrete.
Instead of generic promises, they ask for evidence: testing participation, transparency on subcontractors, clarity on incident notification timelines,
and support for audits/inspections. Providers, in turn, push for standardization so they can meet expectations consistently across customers.
The resultwhen handled wellis less drama and more predictable operational relationships.

Experience #5: Exit planning stops being a bedtime story. Everyone likes the idea of “we can switch providers,” but the first serious
exit drill reveals hard truths: data portability friction, application dependencies, specialized configurations, and timeframes that don’t match the
business’s risk appetite. Organizations that mature here don’t pretend exits are easy; they make them feasible by identifying what must be portable,
documenting migration steps, and reducing lock-in where it matters most.

Across these experiences, one pattern stands out: oversight readiness is less about perfect paperwork and more about operational honestyknowing what
matters, proving controls work, learning from stress tests, and steadily reducing the blast radius of technology failures.

Conclusion

The ESAs’ guide on ICT CTPP oversight is a big step from “policy intent” to “operating model.” It explains the rhythm of designation, planning,
examinations, and follow-upplus the governance and teamwork that aim to keep oversight consistent across the EU financial sector.

If you’re a tech provider serving EU finance, the message is simple: be ready to demonstrate resilience, not just claim it. If you’re a financial entity,
don’t assume oversight replaces your own vendor risk dutiesuse it as an accelerator to strengthen contracting, monitoring, and exit planning.