Article 31: Designation of critical ICT third-party service providers

Article 31 sets the EU process for designating certain ICT third parties as “critical,” which triggers direct oversight at EU level and higher expectations for your own third-party risk controls. To operationalize it, you need a repeatable method to identify which of your ICT providers could be designated, track that status, and be ready to respond to supervisory information requests and remediation actions tied to those providers. (Regulation (EU) 2022/2554, Article 31)

Key takeaways:

• Treat “critical ICT third-party service provider” as a status you must monitor, not a one-time classification. (Regulation (EU) 2022/2554, Article 31)
• Build traceability from services → providers → systemic criticality indicators → governance actions and evidence. (Regulation (EU) 2022/2554, Article 31)
• Implement a regulatory-response workflow so you can execute quickly if a major provider is designated “critical” and oversight actions cascade to you. (Regulation (EU) 2022/2554, Article 31)

For a Compliance Officer, CCO, or GRC lead, the practical challenge behind the article 31: designation of critical ict third-party service providers requirement is speed and coordination. Designation decisions are made by the European Supervisory Authorities (ESAs) through the Joint Committee, based on the Oversight Forum’s recommendation. That means you are not the party doing the designation, but you are still on the hook operationally because designation changes the supervisory environment around a provider you may depend on for core services. (Regulation (EU) 2022/2554, Article 31)

In practice, your goal is to avoid being surprised. You want to know which ICT third parties are likely candidates for designation, understand where they sit in your service map, and have governance and evidence ready for the day your regulator asks: “How are you managing the risks from this dependency?” This page translates the requirement into a set of concrete activities: mapping, monitoring, escalation, recordkeeping, and readiness drills. It also gives you an evidence list and audit questions so you can build once and reuse. (Regulation (EU) 2022/2554, Article 31)

Regulatory text

Provided excerpt: “1. The ESAs, through the Joint Committee and upon recommendation from the Oversight Forum established pursuant to Article 32(1), shall:” (Regulation (EU) 2022/2554, Article 31)

Operator interpretation: Article 31 is a governance “switch.” It establishes that the ESAs (acting via the Joint Committee) will designate certain ICT third-party service providers as critical, based on an internal EU oversight mechanism. Your operational obligation is not to run the ESA’s designation process; it is to be able to (a) identify exposure to providers that could fall into scope, (b) evidence that you can manage the heightened oversight and risk implications, and (c) respond quickly and consistently to supervisory interactions that follow from that ecosystem. (Regulation (EU) 2022/2554, Article 31)

What an operator must be able to do on demand:

• Show which business services rely on which ICT third parties, with clear ownership. (Regulation (EU) 2022/2554, Article 31)
• Show a method for identifying “criticality risk” in your third-party portfolio, even if designation is not yours to decide. (Regulation (EU) 2022/2554, Article 31)
• Show a workflow for regulator-facing requests, escalations, and remediation actions tied to third-party risk. (Regulation (EU) 2022/2554, Article 31)

Plain-English interpretation (requirement-level)

Article 31 means: the EU can designate some ICT providers as critical, and you must manage the downstream impact on your risk posture, governance, and supervisory readiness. If one of your major providers is designated, your regulator will expect sharper answers about concentration risk, exit feasibility, incident coordination, and contractual controls. (Regulation (EU) 2022/2554, Article 31)

Treat the requirement as a standing capability:

• Continuous identification of your most systemic ICT dependencies
• Ongoing monitoring for designation and oversight signals
• A documented response playbook that ties Legal, Procurement, ICT risk, Security, and the business service owner into one path for decisions and evidence (Regulation (EU) 2022/2554, Article 31)

Who it applies to

Entity scope

This matters primarily for DORA-regulated financial entities that rely on ICT third-party services to run important business functions. Even though Article 31 speaks to ESA actions, regulated entities feel the impact through their third-party risk management and supervisory interactions. (Regulation (EU) 2022/2554, Article 31)

Operational context (when you should care most)

Prioritize operationalization when you have:

• Material reliance on a small number of ICT providers (cloud, core banking platforms, payments processing, identity, security monitoring, data/analytics platforms)
• Cross-entity group dependencies where the same provider supports multiple legal entities or critical services
• Complex subcontracting chains where you cannot easily evidence who delivers what (Regulation (EU) 2022/2554, Article 31)

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

1) Establish ownership and a single register for Article 31 readiness

Deliverable: a mapped register that ties Article 31 to controls, owners, and evidence.

• Assign an accountable owner in Compliance or Operational Resilience.
• Assign co-owners: ICT risk, Security, Procurement/Vendor Management, Legal, and key business service owners.
• Build one row per “major ICT dependency” with: provider, service, business function supported, data types, key locations, subcontractors (if known), and internal owner. (Regulation (EU) 2022/2554, Article 31)

Practical tip: If you cannot name a service owner, you cannot run effective exit planning or incident coordination.

2) Define a “potentially critical provider” screening method

Designation is external, but you still need an internal method to prioritize oversight-ready providers. Use criteria you can defend in an exam:

• Service criticality: does the provider support an important business service or customer-facing channel?
• Substitutability: can you move away without severe operational disruption?
• Concentration: do multiple critical services depend on the same provider?
• Operational coupling: are you deeply integrated (identity plane, logging, orchestration, shared runtime)?

Document the method, not just the results. Examiners typically challenge consistency more than the final label. (Regulation (EU) 2022/2554, Article 31)

3) Implement monitoring for designation status and oversight triggers

Create a lightweight monitoring control:

• Track public communications from the provider and your regulator-facing relationship managers.
• Add a “designation status” field: unknown, monitoring, flagged for review, confirmed critical (if you have confirmation).
• Require reassessment when there is a major change: service expansion, acquisition, outage pattern, or contract renewal. (Regulation (EU) 2022/2554, Article 31)

4) Build a regulatory-response workflow (your “day 0” playbook)

When a major provider is under heightened oversight, supervisors may request information fast. Create a workflow with:

• Intake channel (Compliance-owned), triage, and assignment
• Legal review checkpoints for communications
• Evidence pull paths from Procurement, Security, and IT operations
• Escalation to a defined committee for decisions (risk acceptance, remediation commitments, contract changes)
• Tracking of commitments and closure evidence (Regulation (EU) 2022/2554, Article 31)

Where Daydream fits naturally: Many teams fail here because evidence is scattered across ticketing, procurement tools, spreadsheets, and SOC documentation. Daydream can act as the control-and-evidence system of record: map Article 31 to accountable owners, store artifacts, and run a repeatable “regulatory request” workflow with sign-offs and timestamps. (Regulation (EU) 2022/2554, Article 31)

5) Run readiness drills focused on “critical provider dependency”

Do tabletop drills that test:

• Incident notification and coordination paths with the provider
• Decision-making for compensating controls
• Ability to assemble evidence quickly: contracts, SLAs, audit reports, incident postmortems, risk assessments, and remediation status

Capture outputs as audit artifacts: agenda, attendance, scenarios, decisions, and action items to closure. (Regulation (EU) 2022/2554, Article 31)

Required evidence and artifacts to retain

Maintain a clean evidence pack keyed to your Article 31 register:

Governance

• RACI / accountability matrix for ICT third-party oversight
• Committee minutes where major provider risks were discussed and decisions recorded (Regulation (EU) 2022/2554, Article 31)

Inventory and mapping

• ICT third-party inventory with service-to-business-function mapping
• Dependency maps for top providers (including known subcontractors where available) (Regulation (EU) 2022/2554, Article 31)

Screening and monitoring

• Documented screening criteria for “potentially critical” providers
• Monitoring logs and periodic review attestations (Regulation (EU) 2022/2554, Article 31)

Regulatory response

• Written regulator-request SOP (intake, triage, approval, response packaging)
• Evidence of past requests handled (even internal mock requests), including response timelines and sign-offs (Regulation (EU) 2022/2554, Article 31)

Testing and remediation

• Readiness drill records and corrective action plans
• Closure evidence for action items (tickets, change records, updated contracts, new controls) (Regulation (EU) 2022/2554, Article 31)

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your top ICT third parties and the services they support.” (Regulation (EU) 2022/2554, Article 31)
• “How do you decide which providers present systemic dependency risk?” (Regulation (EU) 2022/2554, Article 31)
• “If your cloud provider is designated critical, what changes in your governance and monitoring?” (Regulation (EU) 2022/2554, Article 31)
• “Where is the evidence that third-party risk controls operate, not just exist on paper?” (Regulation (EU) 2022/2554, Article 31)

Hangups that stall audits:

• Inventory lists that don’t connect to business services
• No single owner who can assemble an end-to-end response
• Contract documents and assurance reports stored inconsistently, with no retrieval path (Regulation (EU) 2022/2554, Article 31)

Frequent implementation mistakes (and how to avoid them)

1. Treating designation as “not our problem.”
   Avoidance: document your downstream obligations as “readiness for designation,” with monitoring and response controls. (Regulation (EU) 2022/2554, Article 31)

2. Over-relying on Procurement questionnaires.
   Avoidance: add technical dependency mapping and operational evidence (incident coordination, change management touchpoints, resiliency testing records). (Regulation (EU) 2022/2554, Article 31)

3. No escalation path for contract changes.
   Avoidance: pre-define who can demand amendments, approve remediation spend, or initiate exit planning when a provider risk profile changes. (Regulation (EU) 2022/2554, Article 31)

4. Evidence fragmentation.
   Avoidance: use one control register with pointers to authoritative artifacts and consistent naming, ownership, and retention rules. Daydream is a practical fit if you need that evidence spine without rebuilding your entire GRC stack. (Regulation (EU) 2022/2554, Article 31)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so you should treat enforcement expectations as supervisory readiness rather than case-driven thresholds. The risk is operational: a designated provider concentrates ICT risk across the sector, so regulators tend to probe concentration, substitutability, and your ability to execute governance decisions quickly. (Regulation (EU) 2022/2554, Article 31)

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Name the accountable owner and approve a RACI.
• Build the initial inventory of ICT third parties tied to important business services.
• Draft the “potentially critical provider” screening criteria and pilot it on your top providers. (Regulation (EU) 2022/2554, Article 31)

By 60 days (Near-term)

• Stand up the regulatory-response workflow with Legal sign-off gates and an evidence checklist.
• Add monitoring fields in the inventory and define reassessment triggers.
• Run one readiness drill focused on a top dependency and capture corrective actions. (Regulation (EU) 2022/2554, Article 31)

By 90 days (Operationalized)

• Close the highest-risk corrective actions from the drill and retain closure evidence.
• Produce an “Article 31 readiness pack” you can hand to Internal Audit or supervisors: register, method, monitoring proof, and workflow artifacts.
• Schedule recurring governance reviews for top dependencies and keep minutes. (Regulation (EU) 2022/2554, Article 31)

Frequently Asked Questions

Does Article 31 require my firm to designate a provider as critical?

No. The excerpted text places the designation mechanism with the ESAs through the Joint Committee, based on the Oversight Forum’s recommendation. Your job is to manage the impact on your third-party risk posture and supervisory readiness. (Regulation (EU) 2022/2554, Article 31)

How do I prove compliance if the designation decision is external?

Prove readiness: a documented screening method, a monitored inventory, and an executed workflow for regulatory requests and remediation actions tied to major ICT dependencies. Keep evidence that the controls operate (reviews, drills, and closed actions). (Regulation (EU) 2022/2554, Article 31)

What should I do if a key cloud provider becomes designated “critical”?

Trigger your escalation path: refresh the provider’s risk assessment, validate incident coordination procedures, confirm contractual rights needed for oversight-related requests, and brief the appropriate governance forum with recorded decisions. (Regulation (EU) 2022/2554, Article 31)

Which teams must be involved to operationalize this quickly?

Compliance or Operational Resilience should own the requirement, but you need ICT risk, Security, Procurement/Vendor Management, Legal, and business service owners to provide evidence and execute decisions. Lack of cross-functional ownership is a predictable failure mode. (Regulation (EU) 2022/2554, Article 31)

What artifacts do examiners ask for first?

The dependency map (services to providers), your method for identifying high-impact providers, and proof you can respond quickly to regulator questions with consistent approvals and recordkeeping. If you can’t retrieve contracts, SLAs, and assurance documents on demand, expect findings. (Regulation (EU) 2022/2554, Article 31)

Can I manage Article 31 readiness in spreadsheets?

You can start there, but spreadsheets often fail on access control, versioning, and evidence retrieval under time pressure. A system like Daydream helps by linking the requirement to owners, controls, and artifacts with an auditable workflow for requests and remediation. (Regulation (EU) 2022/2554, Article 31)