Article 42: Follow-up by competent authorities

Article 42 requires critical ICT third-party service providers to respond to Lead Overseer recommendations within 60 calendar days by either committing to follow them or giving a reasoned explanation for not doing so, with that response shared to the financial entities’ competent authorities. Operationalize it by running a time-bound supervisory response workflow with clear owners, decision records, and closure evidence. (Regulation (EU) 2022/2554, Article 42)

Key takeaways:

• Treat Article 42 as a hard deadline and governance requirement for critical ICT third-party providers. (Regulation (EU) 2022/2554, Article 42)
• Build a single “recommendation-to-action” register that ties each recommendation to an owner, decision, plan, and proof. (Regulation (EU) 2022/2554, Article 42)
• Keep regulator-ready evidence: receipt date, internal approvals, response letter, and remediation validation. (Regulation (EU) 2022/2554, Article 42)

Article 42: follow-up by competent authorities requirement is short, but operationally unforgiving. It creates a formal, time-bound expectation that a critical ICT third-party service provider will (a) acknowledge and decide on the Lead Overseer’s recommendations and (b) communicate that decision with enough substance that a competent authority can understand whether the provider will remediate or why it will not. (Regulation (EU) 2022/2554, Article 42)

For a Compliance Officer, CCO, or GRC lead, the fastest path to control is to convert this into a repeatable supervisory-response playbook: intake, triage, accountable ownership, legal/compliance review, executive decisioning, and tracked remediation with validation evidence. The trap is treating recommendations as “advice” rather than a supervisory artifact that must be governed like an enforcement-facing commitment.

Even if you sit at a financial entity rather than a provider, you still need to operationalize the downstream impact: your critical providers’ responses to the Lead Overseer will be transmitted to your competent authority, so you need to know what they committed to, what they rejected, and how that changes your third-party risk posture and continuity assumptions. (Regulation (EU) 2022/2554, Article 42)

Regulatory text

DORA Article 42(1) requirement (excerpt): Within 60 calendar days after receiving recommendations issued by the Lead Overseer (under Article 35(1)(d)), critical ICT third-party service providers must either (i) notify the Lead Overseer they intend to follow the recommendations, or (ii) provide a reasoned explanation for not following them. The Lead Overseer transmits that information to the competent authorities of the financial entities concerned. (Regulation (EU) 2022/2554, Article 42)

Operator interpretation (what you must do):

• Start a compliance clock at receipt. You need an auditable “received on” date and a controlled workflow that drives a response before the deadline. (Regulation (EU) 2022/2554, Article 42)
• Make an explicit decision per recommendation. “We’ll consider it” is not a decision; you must either commit or explain. (Regulation (EU) 2022/2554, Article 42)
• Provide a reasoned explanation when declining. The explanation must be coherent, specific to the recommendation, and internally approved. (Regulation (EU) 2022/2554, Article 42)
• Assume your response becomes supervisory context for your customers’ regulators. Your response is transmitted onward, so write it with that audience in mind. (Regulation (EU) 2022/2554, Article 42)

Plain-English interpretation of the requirement

If you are designated “critical,” the Lead Overseer can issue recommendations. Article 42 says you have a fixed response window to state whether you will implement them. If you won’t, you must explain why in writing, in a way that reads as a defensible governance decision rather than a preference statement. (Regulation (EU) 2022/2554, Article 42)

For financial entities consuming those services, Article 42 is an early-warning signal: if your critical third party declines recommendations, your competent authority will see it. You should be prepared to show how you assessed impact, updated risk treatment, and, where needed, adjusted contracts, controls, or exit planning.

Who it applies to

In-scope entities

• Primary: Critical ICT third-party service providers that receive Lead Overseer recommendations. (Regulation (EU) 2022/2554, Article 42)
• Operationally impacted: Financial entities whose competent authorities receive the provider’s response via the Lead Overseer. (Regulation (EU) 2022/2554, Article 42)

In-scope situations (operational context)

• Receipt of recommendations from the Lead Overseer under the referenced DORA oversight process. (Regulation (EU) 2022/2554, Article 42)
• Any scenario where multiple recommendations arrive across domains (security, resilience, governance, subcontracting). Treat each as a tracked unit of work with its own decision, plan, and evidence.

What you actually need to do (step-by-step)

1) Stand up a controlled intake channel for supervisory recommendations

Goal: eliminate ambiguity about “receipt” and prevent missed deadlines.

• Define one official mailbox/ticket queue for oversight communications (Compliance-owned, monitored, with backup).
• Log every recommendation package with:
  • date/time received
  • sender and reference identifiers
  • affected services/customers
  • attachments preserved in immutable storage

Deliverable: “Supervisory Recommendations Intake Log” (register format).

2) Triage and assign accountable owners within your operating model

Goal: force ownership across functions, not just Compliance.

• Assign a single Recommendation Owner per item (not per document). Typical owners: CISO (security controls), CIO/CTO (architecture/availability), Head of Third-Party Management (subcontractor governance), Head of Risk (risk acceptance).
• Set a RACI that includes:
  • Compliance (process owner, quality gate)
  • Legal (regulatory correspondence review)
  • Engineering/Operations (implementation authority)
  • Executive sponsor (decision authority for declines or major commitments)

Deliverable: RACI + assignment record in the register.

3) Perform a recommendation-by-recommendation decision memo

Goal: create the “reasoned explanation” substrate even if you plan to comply. For each recommendation, document:

• What the Lead Overseer is asking for (plain language)
• Current state (what you already do)
• Gap analysis (what must change)
• Proposed response:
  • Commit to follow (with a realistic remediation plan), or
  • Decline (with a reasoned explanation)
• Impact analysis:
  • operational risk, security risk, customer impact, feasibility constraints
• Approvals: Legal + Compliance sign-off; executive decision where needed

Deliverable: “Recommendation Decision Memo” per item.

4) Draft and approve the formal notification to the Lead Overseer

Goal: produce a regulator-ready response that matches Article 42. Minimum elements:

• Explicit statement of intent to follow or reasoned explanation for not following
• Reference to each recommendation, with a clear mapping
• If following: a structured plan summary (milestones, dependencies, validation approach)
• If not following: rationale tied to facts (scope, technical constraints, alternative controls, timelines, customer segmentation), plus what you will do instead (where appropriate)

Run it through a controlled approval workflow:

• Legal review (tone, commitments, privilege considerations)
• Compliance review (completeness against Article 42)
• Executive approval (risk acceptance / refusal posture)

Deliverable: Signed response letter/email package and approval trail. (Regulation (EU) 2022/2554, Article 42)

5) Track remediation like a supervisory corrective action plan

Goal: avoid “paper compliance” where the response exists but execution does not.

• Convert accepted recommendations into tracked corrective actions:
  • action owner, due dates, dependencies, testing/validation steps
  • status reporting cadence
• Require closure criteria:
  • control implemented
  • evidence captured
  • validation performed (e.g., test results, config snapshots, audit logs)
  • residual risk reviewed and accepted where relevant

Deliverable: Corrective Action Plan (CAP) with validation evidence.

6) Prepare customer-facing and regulator-facing alignment (financial entities)

If you are a financial entity relying on a critical provider:

• Request the provider’s Article 42 response (or a summary) through your third-party governance channel.
• Update your third-party risk assessment and issue management:
  • If the provider declined: record the risk, decide on compensating controls, contract actions, or exit options.
• Pre-draft talking points for your competent authority: what changed, what you did, what you will monitor.

Deliverable: Third-party issue record + risk treatment decision.

Required evidence and artifacts to retain

Keep these in a single evidence pack per recommendation cycle:

• Intake log entry showing receipt date and controlled storage of the recommendation package. (Regulation (EU) 2022/2554, Article 42)
• The recommendation register with unique IDs, owners, and status.
• Decision memo per recommendation (gap analysis, impact, rationale).
• Approval evidence (Legal/Compliance/executive): tickets, sign-off emails, meeting minutes.
• Formal notification sent to the Lead Overseer (final version) and proof of transmission.
• If following: CAP tickets, implementation artifacts, test/validation results, closure sign-offs.
• If declining: final “reasoned explanation” package plus any alternative risk treatment you committed to.

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “How do you prove the receipt date and start of the response clock?” Show the intake log and immutable message retention. (Regulation (EU) 2022/2554, Article 42)
2. “Who can decide to not follow a recommendation?” Auditors look for documented decision authority and risk acceptance governance.
3. “What makes your explanation ‘reasoned’?” They will test specificity: recommendation-by-recommendation rationale, facts, and documented alternatives. (Regulation (EU) 2022/2554, Article 42)
4. “Show me closure evidence for the recommendations you accepted.” Be ready with validation artifacts, not project plans.
5. Financial entities: “How did you respond once you knew your provider declined?” Show updated risk treatment and board/committee reporting where applicable.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails under supervision	Fix
Treating recommendations as informal advice	Article 42 requires an explicit notify/decline response within a defined window. (Regulation (EU) 2022/2554, Article 42)	Run a formal workflow with deadlines, sign-offs, and tracked outcomes.
One global response without per-recommendation decisions	Supervisors need traceability item by item.	Create a register row per recommendation and map response text to each.
“Reasoned explanation” that is vague or purely commercial	Competent authorities expect defensible, control-based rationale. (Regulation (EU) 2022/2554, Article 42)	Use decision memos with facts, constraints, and alternative controls.
No linkage to customer impact	Your response is transmitted to customers’ competent authorities. (Regulation (EU) 2022/2554, Article 42)	Include an impact section: which services/customers are affected and how you mitigate.
Weak evidence discipline	You cannot reconstruct what happened months later.	Store an evidence pack with immutable retention and clear ownership.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for Article 42, so this page does not list enforcement examples.

Operational risk still concentrates here:

• A missed deadline or unclear response becomes a supervisory escalation risk because your position is communicated to competent authorities of impacted financial entities. (Regulation (EU) 2022/2554, Article 42)
• Declining recommendations, even with a reasoned explanation, can trigger customer scrutiny, contractual pressure, and heightened monitoring by financial entities’ oversight functions.

Practical 30/60/90-day execution plan

You asked for fast operationalization; here is a plan you can execute without waiting for a designation event.

First 30 days (foundation)

• Create the supervisory recommendation intake channel, log template, and evidence repository.
• Publish an internal SOP: “Lead Overseer Recommendation Response,” with roles and approvals. (Regulation (EU) 2022/2554, Article 42)
• Build the recommendation register format (fields: receipt date, item, owner, decision, response status, CAP link, evidence link).
• Agree the executive decision path for declines (risk acceptance governance).

Days 31–60 (run it end-to-end)

• Tabletop drill: simulate receipt of recommendations and produce a draft response package.
• Pressure-test the “reasoned explanation” template with Legal and Risk.
• Integrate the CAP workflow with your existing issue management tool (one ID from recommendation to closure).

Days 61–90 (operational hardening)

• Define validation standards for closure evidence (what “done” means).
• Add customer communication triggers for financial entities (what you disclose, when, and through which channel).
• Implement metrics that do not require statistics: aging of open recommendations, overdue actions, and evidence completeness checks.

Where Daydream fits naturally: Daydream can act as the system of record that ties Article 42 obligations to concrete ICT controls, named accountable owners, and a regulator-ready evidence pack, so you can answer supervisory follow-up questions without rebuilding the story from tickets and email threads.

Frequently Asked Questions

Does Article 42 apply to financial entities or only to critical ICT third-party service providers?

The explicit 60-calendar-day notify-or-explain obligation is on critical ICT third-party service providers. Financial entities are impacted because the Lead Overseer transmits the provider’s response to their competent authorities. (Regulation (EU) 2022/2554, Article 42)

What counts as a “reasoned explanation” for not following recommendations?

Article 42 requires an explanation that is more than a refusal. In practice, write a recommendation-specific rationale based on facts (scope, constraints, risk tradeoffs) with documented internal approvals. (Regulation (EU) 2022/2554, Article 42)

How should we track multiple recommendations received in a single package?

Split them into separate register entries with separate owners and decisions, even if the outbound response is a single letter. That structure gives you traceability from each recommendation to a decision and closure evidence.

As a financial entity, should we request our provider’s Article 42 response?

Yes. Since your competent authority receives the provider’s position, you need the same information to update your third-party risk treatment, compensating controls, and exit planning assumptions. (Regulation (EU) 2022/2554, Article 42)

What evidence do examiners typically want first?

They usually start with (1) proof of receipt date, (2) the decision record per recommendation, and (3) the final notification sent to the Lead Overseer, with approvals and transmission proof. (Regulation (EU) 2022/2554, Article 42)

Can we commit to follow recommendations without providing detailed implementation milestones?

Article 42 requires you to notify your intention to follow; it does not specify milestone granularity in the excerpt provided. Operationally, include enough plan detail to show intent is real and governed, then track execution in your CAP evidence pack. (Regulation (EU) 2022/2554, Article 42)