Article 42 DORA follow-up by competent authorities

What DORA Article 42 asks financial entities to do after critical provider recommendations

If your bank, payment institution or insurer uses a critical ICT third-party provider, Article 42 governs what happens after the Lead Overseer issues recommendations to that provider. It covers the provider's 60-day response window, public disclosure if the provider does not respond adequately, your duty to take the identified risks into account, and the last-resort power of competent authorities to require you to suspend or terminate use of the service. Your first job is not to wait for the provider's answer. It is to find out, from your competent authority, which risks the recommendations concern and how they touch the services you rely on.

This is a different obligation from the contracting duties in Article 28 and the oversight powers in Article 35. Article 28 governs what you check and write into contracts before you buy. Article 35 governs what the Lead Overseer may demand from the provider. Article 42 sits between them: it is the point where a finding about a provider becomes a decision you must reflect in your own arrangements, and where your authority can tell you to act within a set period. Article 42(8) also requires authorities to give you enough time to adjust contracts and deploy exit strategies and transition plans, so the clock they set is a planning constraint, not a formality.

Three things usually make this hard. Many contracts predate the recommendations and contain no mechanism to change service terms, add remediation obligations or trigger termination on a critical finding. Exit plans, where they exist, were often written for a generic failure and have not been tested against a forced suspension of a provider used across several functions. Tracking is weak: recommendations reach the entity through the competent authority, but no one owns the register that links each recommendation to affected services, contracts and owners. Confirm with your authority how and when it will communicate recommendations, and check that your register of information and exit plans can be updated within days, not months.

Which entities, contracts and services Article 42 touches

Article 42 follows a recommendation chain that starts with a designated critical provider and reaches financial entities only through their own contracts. The cards below separate the duties that belong to the provider from the duties that depend on what each financial entity has signed, bought and subcontracted.

Financial entities using a designated provider

Article 42 reaches a financial entity only when it uses a provider the ESAs have designated as critical. Start with the register of information and match each ICT provider against the published designation list. Record which of your services run on that provider, which business functions they support, and which contract governs them. An entity that uses a designated provider only indirectly, through a reseller or a managed service, should confirm that chain with its contracting party.

Contracts supporting critical or important functions

The entity's duties under Article 42 turn on whether a contract supports a critical or important function. Review each agreement with a designated provider and check whether it covers a service whose failure would impair the entity's regulated activity. Confirm that the contract gives the entity the information, termination and exit rights it would need if the competent authority requires suspension or termination. Contracts that lack these terms are the first gap to close.

Subcontracted chains named in recommendations

Recommendations to a critical provider may point to a subcontractor, a data center or a software component that the provider depends on. Map the provider's subcontracting chain as far as your contracts allow, and note which of your services pass through each link. Ask the provider for its subcontracting list and for notice of changes. If a recommendation names a link you cannot see, treat that as a visibility gap to escalate.

Intra-group and cloud dependencies

A designated provider may be a cloud platform or a group company that serves several entities in the same corporate structure. Identify every entity that consumes the same provider, including intra-group arrangements that are not billed as separate contracts. Check whether a cloud region, account or shared platform could be suspended for one entity and affect others. Decide in advance who in the group coordinates the response and who holds contract authority.

Self-hosted open-source components

Open-source software you run in your own cloud account or data center is usually not a contracted service from a designated provider, but it can sit underneath one. Record which self-hosted platforms depend on a designated provider for hosting, identity, backup or support. Confirm with your legal team whether an open-source component you buy support for falls within a contract. The question to answer is which of your systems would stop if a designated provider were suspended.

Who owes what: provider versus entity

The provider owes the 60-day response to the Lead Overseer. The entity's duties depend on its own contracts and on the risks that competent authorities pass on to it. Keep the two obligations separate in your plan: track the provider's notices and public disclosures, and separately test whether your contract lets you act on the risks in a recommendation. Confirm with your competent authority which timelines apply to your entity once it receives a warning.

How supervisors test the follow-up chain

This table sets out what a competent authority checks at each step after a Lead Overseer's recommendations, the evidence it asks for, and the findings that most often lead to escalation. Read it as a sequence: each row tests a link the financial entity must be able to show, from receiving the risks to deciding on a contract change or exit. The main takeaway is that undocumented decisions are treated as unaddressed risks.

Supervisory check	What the authority tests	Evidence it typically requests	Common findings
Provider response	Whether the critical provider followed recommendations or gave a reasoned explanation, assessed under Article 6 of Delegated Regulation (EU) 2025/295	Provider notification to the Lead Overseer, the authority's copy of the response, and the entity's own record of what was received	Entity relies on the provider's general assurances without reviewing the substance of the response
Receipt of identified risks	Whether the financial entity was informed of the risks identified in the recommendations that affect its services	Dated correspondence from the authority, internal distribution records, and the list of affected services and functions	No record of who received the notice, or it was filed without assessment
Entity assessment	Whether the entity took the identified risks into account in its ICT risk management and third-party decisions	Risk assessment updates, residual risk records, and minutes showing management body review	Undocumented risk acceptance, or a generic statement that the risk is 'monitored'
Contract changes after a warning	Whether contractual arrangements were amended to address the risks within the period set by the authority's warning	Amended contract or addendum, negotiation trail, dates of signature, and the clauses that now cover the identified risks	Warning received but amendments are drafted late, unsigned, or do not address the specific weakness
Exit and transition readiness	Whether the entity can move the service or suspend it without disrupting critical or important functions	Tested exit plan, transition plan, data return and deletion procedures, and alternative provider options	Missing or untested exit plan, or exit steps that rely on the same provider
Proportionality of suspension or termination	Whether a last-resort order would be proportionate, weighing gravity, duration, serious weaknesses, financial crime links, intent and continuity risk	Impact analysis on critical functions, service dependency map, and continuity arrangements for a partial or full suspension	Impact analysis not updated, so the entity cannot show how long it could operate without the service
Time to adjust	Whether the entity was given and used enough time to adjust contracts and deploy exit or transition plans	Project plan with milestones, status reports to management, and records of escalations	Adjustment plan starts only after the authority's deadline, with no interim controls

How a financial entity implements the Article 42 response

The sequence turns a competent authority's warning about a critical provider's risks into recorded decisions, contract or operational changes, and a tested fallback plan. Each step produces a document or check that an examiner can follow from the original recommendation to the final position.

Record and classify each recommendation
Log every recommendation the competent authority passes on, with the date received, the critical provider concerned, the risk it describes and the authority's reference. Classify each one by severity and by the operational function it touches, so the team can see which items affect critical or important functions. The output is a dated recommendation register owned by the risk or third-party function, reviewed by the management body or its delegate. The step closes when every item has an owner and a classification.
Map affected contracts and services
Use the register of information to identify each contract, sub-contracting chain and ICT service that depends on the provider named in the recommendation. Trace which business functions, data flows and legal entities rely on those services, including services the provider delivers through its own subcontractors. The output is a service map that links each recommendation to specific contracts and functions. The step is complete when the team can state which functions would be affected if the service were suspended in part or in full.
Assess the risk against own operations
Test each identified risk against the entity's own operations, not against the provider's general position. Consider the gravity and duration of the weakness, whether it has already affected the entity, the availability of substitute providers, and the time needed to move workloads. Record the residual risk that remains if no contract change is made. The output is a signed risk assessment per recommendation, stating the impact, the likelihood and the owner's conclusion on whether the current arrangement is acceptable.
Agree contract and operational changes
Negotiate with the provider the changes needed to address each risk, such as remediation commitments, enhanced audit or reporting rights, subcontracting controls or service-level adjustments. Where the provider does not agree, document the refusal and the options considered. Track each change to a named deliverable and date. The output is an amended contract, a side agreement or a documented operational control, plus a log showing whether the risk is addressed. This work must finish within the window the competent authority has set in its warning, so the team should confirm that window with the authority at the outset.
Document decisions and timelines
Keep a decision record for each recommendation that states what was decided, who approved it, the evidence relied on and the dates of each action. Include the reasoning behind any decision not to change a contract, since the authority may ask for it. Link the records to the register of information and to the relevant ICT risk management documentation. The output is an auditable file that an examiner can read without interviews. The step closes when each record has an approver and each action has a verified completion date.
Prepare the exit strategy and transition plan
Where the risk is not resolved in time, prepare the exit strategy and transition plan that Article 42(8) contemplates. Define the alternative providers or in-house options, the data migration path, the staffing and the sequence in which functions would move. Estimate the time each transition would take, using the entity's own testing results rather than assumptions. The output is a tested exit plan with defined triggers and fallback options, approved by the management body. Ask the provider and the internal team to confirm the plan is achievable before relying on it.
Test the fallback and maintain the register
Run a table-top or technical exercise of the exit or suspension scenario to confirm that the transition steps, data restores and communications work as documented. Record the results, gaps and corrective actions. Update the register, the risk assessment and the exit plan with any findings. The output is a test report and a current register showing the position for each recommendation. This step closes the cycle, and it also prepares the entity for any direction to suspend or terminate use of the service.

How the 60-day and warning periods interact in practice

The Article 42 process runs on regulatory clocks that do not wait for each other. The critical provider has 60 calendar days from receiving the Lead Overseer's recommendations to notify the Lead Overseer that it will follow them or to give a reasoned explanation for not doing so. If the provider stays silent or its explanation is insufficient, the Lead Overseer may publicly disclose the provider's identity and the nature of the non-compliance, subject to the proportionality and financial stability safeguards in Article 42(2). That disclosure is a separate clock with its own trigger, and the provider's response window closes before the financial entities learn the outcome. Financial entities therefore cannot assume that a provider's silence will be resolved by the time the competent authority acts. The second clock belongs to the competent authority. Under Article 42(3) and (4), the authority informs your organization of the risks identified in the recommendations and expects those risks to be reflected in your decisions. If your contractual arrangements do not address the risks, the authority may warn you that a decision may follow within 60 calendar days. Read the two periods together: the provider's 60 days and the authority's 60-day warning window are both measured in calendar days, but they start from different events. Confirm with your competent authority when it considers the warning issued and how it expects to receive your response, because the provider's response date will not tell you when your own window opens. The regulatory timelines set outer limits, not your operating plan. Your ICT third-party risk policy should state who receives the Lead Overseer's communications, how quickly the contract owner, legal, and the risk function must assess a provider's response, which contract amendments or exit steps are authorized before a warning arrives, and who decides whether to start an exit plan or contingency. Article 42(8) requires authorities to give entities enough time to adjust contracts and deploy exit strategies and transition plans, but that time is only useful if your own timelines are tested in advance. Ask your provider and your counsel to confirm how the provider notifies you of its response and what information it will share.

Evidence that shows the entity responded to identified risks

Article 42 asks whether a financial entity acted on the risks that supervisors identified in their dealings with a critical provider. The cards below are the records a supervisor will ask to see, and each one should tie back to the same recommendation and the same affected service. Keep them dated, versioned and linked so that the story holds together from notice to decision.

Authority notice and recommendation summary

Keep the notice from the competent authority that informs you of the risks identified in the Lead Overseer's recommendations, with the date you received it. Store a short summary alongside it that lists each risk, the provider function it affects and the deadline your authority set for your response. This is the anchor document: every other artifact should point back to a specific item in it. Check that the summary uses the authority's wording so that a reviewer can match each risk without interpretation.

Service-specific risk assessment

Produce a risk assessment for the particular ICT service affected, not a generic review of the provider. It should describe the function that depends on the service, the failure modes the recommendation raises, the impact on your operations and clients, and the residual risk after the measures you chose. Date it, name the reviewer and show the version history. A supervisor will test whether the assessment reflects your actual dependency, including subcontractors and data locations.

Contract amendments and side letters

Where the risks can only be addressed through the contract, collect the signed amendments or side letters that add or change rights, such as audit access, incident notification timelines, subcontracting controls or exit support. Compare each clause with the risk it answers so that gaps are visible. Confirm that the amended terms are the ones in force, not drafts, and that the register of information reflects them. Legal review of these documents is usually a separate cost from the technical work.

Documented risk acceptance

Where you decide to keep a residual risk, record the decision as a formal acceptance with the rationale, the compensating controls, the conditions for review and an expiry date. The management body must sign it, and the minutes should show that it did. Supervisors look for acceptances that are vague, unsigned or never revisited. Avoid accepting a risk the recommendation required you to remove, unless you can explain why the authority's concern no longer applies.

Updated register of information entries

Update the entries for the affected provider and service in your register of information so that they describe the arrangement as it now stands. Record changes to subcontractors, data locations, contract terms and substitutability assessments, and keep the change history. Mismatches between the register and the contract or risk assessment are a common reason a response looks incomplete. Confirm the format your authority requires before the next reporting cycle.

Tested exit and transition plans

Maintain exit and transition plans for each critical or important service that the recommendation touches, covering a partial or full suspension as well as termination. The plan should name replacement options, data return steps, migration sequence, owners and the time needed to move workloads. Test the plan through a tabletop or technical exercise and record the results and the gaps found. A plan that has never been run gives a supervisor little evidence that suspension is survivable.

Minutes showing timely review

Keep minutes from management body and risk committee meetings that show the recommendation was tabled, discussed and decided within the deadlines you set. Record attendance, the questions raised and the actions assigned with owners and dates. Minutes that repeat the same action across several meetings signal stalled follow-up. Link each action to the artifact it produced so the trail from notice to decision is easy to follow.

What responding to a recommendation costs and what drives it

This table lists the cost components a financial entity or critical provider meets when responding to Article 42 recommendations, who pays for each, and whether the work is one-time or recurring. Use it to shape a quote request, since no supplied fact gives a figure for these costs and the real amounts depend on the affected services and contracts.

Cost component	Who carries it	One-time or recurring, and what drives it
Internal legal and third-party risk review	Financial entity (its legal, procurement and TPRM staff)	Mostly one-time per recommendation cycle; rises with the number of contracts reviewed and how many risks the competent authority names
Contract renegotiation with the critical provider	Financial entity, with the provider's contract and legal team	One-time per amended agreement; depends on contract complexity, existing audit and exit clauses, and how willing the provider is to change terms
Architecture changes to support partial suspension	Financial entity, with its internal platform team and any implementation partner it engages	One-time build, with ongoing run costs; depends on how tightly the critical service is wired into business processes and whether traffic can be isolated
Exit strategy and transition plan preparation	Financial entity, often with an external advisor	One-time to document, recurring to keep current; depends on exit feasibility, data portability and how many functions rely on the service
Exit testing and dry runs	Financial entity, with the provider's cooperation and any external tester	Recurring as tests are repeated; depends on the number of affected services, test scope and whether production data must be used
Monitoring of provider remediation	Financial entity, with its operations and risk functions	Recurring until the risks are closed; depends on reporting frequency the provider accepts and how many risks remain open
External review or independent assessment	Financial entity engages and pays the reviewer; the provider may bear its own assessment costs	Varies by engagement; the reviewer issues findings to the entity and does not issue DORA certification, which DORA does not provide for
Provider-side remediation and response	Critical ICT third-party provider, which must respond within 60 calendar days under Article 42(1)	Provider's own cost, but passed on in pricing or contract terms if the entity negotiates for it; rises with the number of recommendations and affected clients

How self-hosted open-source platforms affect exit and suspension planning

A self-hosted open-source platform running in the financial entity's own infrastructure does not remove the need to respond to Article 42. If a critical ICT third-party provider's service is at risk of suspension or termination, the entity still has to assess its exposure, follow the competent authority's instructions and adjust its contracts. What self-hosting changes is feasibility. The entity holds the data, controls the deployment and can keep the service running if a vendor relationship breaks down, which makes a temporary suspension or exit far more practical to execute than with a fully hosted SaaS dependency. Treat that advantage as something to test, not assume: check whether the entity can actually run, patch and restore the platform without the upstream provider's involvement.

Before relying on that position, verify two things. First, confirm the support arrangements: who provides security patches, upgrades and incident assistance for the open-source components, whether that is a commercial subscription, a contracted implementation partner or the entity's own engineers, and what happens if that party is itself a critical provider under review. Second, confirm the licensing terms for the entity's intended use, including any obligations that apply if the software is modified or offered to third parties. Record both in the exit plan and in the register of information so the competent authority can see the dependency chain.

CISO Assistant (AGPL-3.0-only) can support this work by recording audits, assessments and framework mappings, and it ships with DORA among its more than 200 frameworks. An entity can use it to log which critical provider risks were identified, which contractual changes were agreed and which transition steps were tested, with the evidence attached. Confirm the AGPL-3.0-only license against the entity's own deployment, modifications and any external access before treating it as the system of record. The software records the entity's assessments, but the judgments about risk, sufficiency of contract changes and exit timing remain the entity's own decisions, and any independent review still has to come from a qualified outside party.

Who owns the response, who prepares evidence and who decides

The financial entity owns every decision that follows a recommendation. The management body is accountable for accepting the ICT third-party risk it still carries, and it must take the identified risks into account when it decides whether to keep, modify or exit the arrangement. Third-party risk, legal and operations teams carry the work of turning those decisions into contract amendments, timelines and service changes.

Management body decisions: Record which risks are accepted, mitigated or require exit, and the reasoning behind each choice.
Third-party risk function: Own the register of information entries, the monitoring of the provider's response and the escalation path.
Legal and procurement: Negotiate contract changes, subcontracting terms and any exit or transition clauses with the provider.
Operations teams: Run any temporary service adjustments and confirm continuity during the change window.
Internal audit: Test whether the decisions and their records hold up over time.

Confirm that the named owner for each decision is written into the response plan and that the management body has minuted its approval before any deadline.

Where entities usually fall short on Article 42

Article 42 only bites once a critical provider has been given recommendations and the financial entities using its services must act on the risks identified. The gaps below tend to surface at that moment, when a notice arrives and the team discovers that nobody owns it, the contract has no way to change, or the exit plan has never been run.

No process to receive authority notices

Competent authorities pass on the risks identified in recommendations to financial entities, and the notice may reach a procurement mailbox, a vendor manager or nobody in particular. Article 42 expects the entity to take those risks into account, so the response clock starts before the right people have seen the message. Confirm a named owner, a routing rule from the ICT register to the risk committee, and a tested path for escalating to the management body.

Contracts without change mechanics

Many ICT contracts let the provider change its service, location or subcontractors, but give the customer no right to require remediation. If an authority warns that a decision may follow within 60 calendar days, the entity may have no contractual lever to make the provider address the risk. Check for a change-request clause, a remediation timetable, a right to suspend use, and termination triggers tied to regulatory findings.

Exit plans never tested

An exit plan written for the file but never run is the most common reason a suspension or termination order becomes an operational outage. Article 42 gives authorities the power to require temporary suspension or termination, and the entity needs time to deploy an exit strategy and transition plan. Run a tabletop exercise on the critical service, record the data export time and confirm that a replacement or fallback exists.

Risk acceptance disconnected from the recommendation

Risk registers often record a generic accepted risk for a provider without linking it to the specific weakness an authority identified. When the recommendation later arrives, the entity cannot show whether its earlier decision still holds. Tie each accepted risk to the recommendation or finding, set a review date, and record who approved it and what compensating controls apply.

Inconsistent tracking across the register

Information about a critical provider often sits in several places: the register of information, the contract file, the risk register and the incident log. When these disagree on which services the provider supports and which functions depend on them, the entity cannot quickly show which of its arrangements a recommendation affects. Reconcile the register against the contracts and the provider's listed services each quarter, and assign one owner for updates.

Questions buyers ask about Article 42 readiness

Does Article 42 apply if we do not use a critical ICT provider?

Only indirectly. The Article 42 steps follow recommendations that the Lead Overseer addresses to a critical ICT third-party service provider, so they reach your entity only when one of your providers has been designated critical and its recommendations are in play. Even without such a provider, your entity keeps its other DORA duties for ICT third-party risk, including the register of information, contract clauses and exit planning. Confirm with your competent authority whether any provider in your supply chain appears on the designated list, because subcontractors and indirect dependencies can bring a provider into scope without your team noticing. Keep a short, dated record of that check so you can show the decision if an authority asks. The article text is available on EUR-Lex.

How long do we have to respond after a warning from our authority?

Under Article 42, the deadline is 60 calendar days, and it starts from the warning your competent authority gives you. The provider's own 60-day window under Article 42(1) runs separately, from the moment it receives the Lead Overseer's recommendations. Your authority may warn you that a decision could follow within 60 calendar days if your contractual arrangements do not address the identified risks. Confirm with the authority how it will deliver that warning, who must receive it, and what proof of response it expects. Plan internal approvals against that window, because contract changes usually need legal review, management body sign-off and procurement steps. Ask whether the authority sets interim reporting dates inside the 60 days.

Can we handle Article 42 readiness in-house?

Many entities can run the response internally if they have the people and records to do it. The work spans risk management, legal, procurement and the team that owns the affected ICT service, so no single function can carry it alone. Whether in-house work is practical depends on how many contracts reference the affected provider, whether your register of information is current, whether your exit and transition plans have been tested, and whether anyone has mapped the provider's subcontracting chain. If several of these are weak, an outside partner can help prepare systems, documentation and evidence on a fixed scope agreed in writing. Ownership of the controls, the decisions and the regulator relationship stays with your organization in either case.

What work must our entity supply to respond to Article 42 follow-up?

The entity must supply evidence that it has taken the identified risks into account and addressed them in its contractual arrangements. In practice, that usually means:

The current contract, its clauses and any proposed amendments to address the risks
Register of information entries for every service that depends on the affected provider
A risk assessment of the identified risks, with the mitigations and residual risk recorded
Exit and transition plans, showing how services could move or be suspended if the authority requires it
Evidence that the management body reviewed the position and approved the response

Ask your authority which format it expects and whether it accepts submissions through specific channels. Keep these records current, because the authority may ask for them at short notice.

What drives the cost of Article 42 readiness?

No public price applies to this work, so cost depends on the scope of your exposure. The main cost components are internal staff time, legal review of contracts, negotiation with the provider, and any outside consultant or technical contractor you engage. Costs rise with the number of contracts and services that depend on the affected provider, the depth of the subcontracting chain, the complexity of moving or suspending a service, and how much the data and records need to be rebuilt. Some work is one-time, such as the initial response and contract changes, while register updates, monitoring and exit plan testing recur. The authority's assessment approach is set out in Delegated Regulation (EU) 2025/295. When you request a quote, ask for a written scope that lists the deliverables, the services covered, the assumptions and the exclusions.

Can an implementation partner represent our entity to the competent authority?

A partner can prepare the material, but it should not speak for your entity on regulatory matters without a clear mandate that your legal counsel has approved and that your authority accepts. Your entity owns the relationship with its competent authority, and it is responsible for the positions it takes. An implementation partner can prepare systems, controls, documentation and evidence, brief your team before meetings, and help you organize records for submission. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it does not act as the regulator's counterpart. Confirm with your authority in advance how it handles third-party representatives and what documents it expects you to sign personally.

How DeployOpen prepares systems and evidence for Article 42

DeployOpen works on the systems and evidence a financial entity needs when its critical ICT provider must answer Lead Overseer recommendations and when its own contracts must address the risks identified. Our role is to prepare the self-hosted platforms, controls and records in the client's own infrastructure, while the competent authorities and the ESAs make the supervisory decisions.

How we scope

Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
The written scope names which self-hosted platforms, contracts and ICT services are covered by the Article 42 follow-up work.
Scope confirms which evidence the entity expects to hold for risks flagged in recommendations, and who owns each item.

How we build

We map identified risks to specific controls, configurations and contract clauses in the client's environment.
We document remediation steps, owners and dates so the entity can show how it addressed each risk it was told about.
We set up records of exit strategies and transition plans for the services a competent authority could require the entity to suspend or replace.

How we hand over

We deliver the documentation, configuration records and evidence files in a form the client's own teams and auditors can review.
Handover covers what the client must maintain, who approves changes and how new recommendations are logged and tracked.
The client remains the decision maker for contract changes, supervisory responses and any submission to a competent authority.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover updates to evidence when a provider responds to new recommendations or when the entity's contracts change.
Confirm with DeployOpen which support level fits your timeline, your internal ownership and your supervisory calendar before signing.