Article 29: Preliminary assessment of ICT concentration risk at entity level

Article 29 requires you to perform a preliminary ICT concentration risk assessment before entering or materially changing a contract for ICT services that support a critical or important function, and to factor concentration outcomes into the Article 28(4)(c) third-party risk assessment. You must identify whether the deal increases dependency on a provider, technology, or geography, and document the decision. (Regulation (EU) 2022/2554, Article 29)

Key takeaways:

• Trigger the assessment at “envisaged conclusion” of a contract for ICT supporting critical/important functions, not after signature. (Regulation (EU) 2022/2554, Article 29)
• Treat concentration as an entity-level risk decision that can block, reshape, or require mitigations for the contracting path. (Regulation (EU) 2022/2554, Article 29)
• Keep auditable evidence: service mapping, concentration analysis, decision record, and mitigation plan tied to the contract lifecycle. (Regulation (EU) 2022/2554, Article 29)

Article 29: preliminary assessment of ICT concentration risk at entity level requirement is one of the fastest ways supervisors test whether your third-party risk management is real or just contract hygiene. The rule is narrow in wording but broad in impact: whenever you are about to sign (or significantly change) an ICT services contract that supports a critical or important function, you must check whether the arrangement creates or worsens concentration risk at the entity level. (Regulation (EU) 2022/2554, Article 29)

Operationally, this means you need a repeatable “concentration check” embedded in procurement, outsourcing governance, and change management. The output is not a theoretical report. It is a go/no-go input into the contracting decision, with documented rationale and, where needed, constraints like exit measures, multi-region design, substitution options, or service decomposition.

This page translates Article 29 into an execution playbook a Compliance Officer, CCO, or GRC lead can put in place quickly: scope, triggers, roles, steps, artifacts, exam questions, and common failure modes. All guidance below should be implemented in a way that produces evidence you can hand to a competent authority on request. (Regulation (EU) 2022/2554, Article 29)

Regulatory text

Excerpt (provided): “When performing the identification and assessment of risks referred to in Article 28(4), point (c), financial entities shall also take into account whether the envisaged conclusion of a contractual arrangement in relation to ICT services supporting critical or important functions would lead to any of the following:” (Regulation (EU) 2022/2554, Article 29)

Operator interpretation: Article 29 adds a required lens to your Article 28(4)(c) third-party risk assessment: concentration risk at the entity level must be evaluated before you conclude the contract (“envisaged conclusion”) when the ICT service supports a critical or important function. Your process must detect whether the new arrangement increases dependency concentration, and you must show how that finding influenced the contracting decision. (Regulation (EU) 2022/2554, Article 29)

What this means in practice:

• Concentration risk is not limited to “one vendor.” It includes dependency clustering (same provider group, same hyperscaler, same geography, same critical subcontractor, or same technology stack) that could create correlated failure. (Regulation (EU) 2022/2554, Article 29)
• “Preliminary assessment” is an early gating assessment. You can refine it later, but you cannot skip it until after contracting. (Regulation (EU) 2022/2554, Article 29)

Plain-English interpretation of the requirement

You must run a documented check, during pre-contract due diligence, to answer: “If we sign this ICT deal for a critical/important function, do we become overly dependent on a provider, provider group, location, or shared component such that a single issue could disrupt us across multiple services?” If yes, you either redesign the sourcing approach, add mitigations, or do not proceed. (Regulation (EU) 2022/2554, Article 29)

This is entity-level. A business unit cannot approve a “local optimum” that creates a firm-wide dependency without senior risk visibility.

Who it applies to (entity and operational context)

Applies to: Financial entities in scope of DORA entering contractual arrangements for ICT services that support critical or important functions and performing the risk identification/assessment referenced by Article 28(4)(c). (Regulation (EU) 2022/2554, Article 29)

Operational contexts that should trigger Article 29 concentration checks:

• New outsourcing or cloud adoption for a critical/important function. (Regulation (EU) 2022/2554, Article 29)
• Material renewals, scope expansions, or migrations that deepen dependency (for example, moving a core workload to a managed service on the same provider). (Regulation (EU) 2022/2554, Article 29)
• Major architecture decisions tied to the contract (region selection, single-tenant vs shared, proprietary managed services). (Regulation (EU) 2022/2554, Article 29)

Functions in scope: Whatever your internal framework classifies as critical/important under DORA governance. If you do not have a defensible classification method, you will struggle to justify when Article 29 is triggered. (Regulation (EU) 2022/2554, Article 29)

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

Step 1: Define the trigger and embed it in the contracting workflow

Create a mandatory workflow gate: “Does this ICT service support a critical or important function?” If yes, require a concentration assessment before the contract can be submitted for approval. (Regulation (EU) 2022/2554, Article 29)

Implementation detail: Add a required field in your intake (procurement, outsourcing register, or third-party onboarding) that maps the service to a function classification and an application/service owner attestation.

Step 2: Build and maintain an ICT dependency map you can query

You cannot assess concentration without knowing existing dependencies. Maintain a living inventory that ties:

• critical/important functions → business services → applications → infrastructure/platform dependencies → third parties (including subcontracting where known). (Regulation (EU) 2022/2554, Article 29)

Minimum viable approach: start with critical/important functions only; expand coverage later. The assessment is “preliminary,” but it still must be grounded in real service mapping. (Regulation (EU) 2022/2554, Article 29)

Step 3: Perform the preliminary concentration assessment for the envisaged contract

For the proposed contract, evaluate concentration across practical “correlated failure” dimensions:

Concentration dimensions (use as a checklist):

• Provider concentration: Are we increasing reliance on one ICT third party or provider group for multiple critical/important functions? (Regulation (EU) 2022/2554, Article 29)
• Service concentration: Are multiple critical services dependent on the same ICT service (for example, the same IAM, network, or observability layer) provided externally? (Regulation (EU) 2022/2554, Article 29)
• Geographic concentration: Does the design concentrate workloads in one region/country/zone in a way that creates a single point of failure? (Regulation (EU) 2022/2554, Article 29)
• Technology concentration: Does the contract drive adoption of proprietary managed components that are hard to replace, increasing switching friction? (Regulation (EU) 2022/2554, Article 29)
• Subcontractor/4th-party concentration (where visible): Does the provider rely on the same upstream for critical parts of delivery (connectivity, datacenter operator, security tooling)? (Regulation (EU) 2022/2554, Article 29)

Output: a short, decision-grade memo (or structured record) with: current-state dependencies, proposed change, concentration findings, risk rating, required mitigations, and an approval decision.

Step 4: Decide and document risk treatment before signature

If concentration increases, document which path you chose:

• Avoid: pick an alternative provider or architecture.
• Reduce: multi-region, multi-zone, service decomposition, portability requirements, escrow/backup arrangements, dual-provider patterns where feasible.
• Transfer/accept: only with explicit risk acceptance, named accountable executive, and recorded rationale. (Regulation (EU) 2022/2554, Article 29)

Tie the decision back to the contracting approval record so you can prove the assessment influenced governance. (Regulation (EU) 2022/2554, Article 29)

Step 5: Carry mitigations into contract controls and ongoing monitoring

A preliminary assessment is wasted if mitigations never become binding obligations. Translate mitigations into:

• contract clauses and schedules (service scope, audit/assurance, resilience expectations, exit support), and
• operational controls (resilience testing plans, exit runbooks, dependency monitoring). (Regulation (EU) 2022/2554, Article 29)

Practical operator tip: Put a “concentration-driven requirements” section in the contract playbook so Legal and Procurement do not treat the assessment as informational.

Step 6: Make it inspectable (supervisory-ready)

Supervisors will test consistency: same trigger, same method, same evidence. Standardize with templates and a register entry per in-scope contract. (Regulation (EU) 2022/2554, Article 29)

Where Daydream fits: Daydream is useful when you need traceability from Article 29 to accountable owners, control steps, and evidence artifacts across many third parties, plus a workflow for escalations and remediation closure that stands up under supervisory review. (Regulation (EU) 2022/2554, Article 29)

Required evidence and artifacts to retain

Retain artifacts in a way that is easy to produce per contract and also roll up to entity-level reporting.

Core evidence pack ¹:

• Critical/important function classification and service mapping record. (Regulation (EU) 2022/2554, Article 29)
• Preliminary concentration risk assessment (structured form or memo) dated before contract conclusion. (Regulation (EU) 2022/2554, Article 29)
• Dependency map extract showing existing concentrations and what changes with the new contract. (Regulation (EU) 2022/2554, Article 29)
• Approval record showing review/decision, including risk acceptance if applicable. (Regulation (EU) 2022/2554, Article 29)
• Mitigation plan and proof it was implemented (contract schedule references, architecture decisions, testing plan, exit plan). (Regulation (EU) 2022/2554, Article 29)

Entity-level artifacts:

• Concentration risk methodology and scoring rubric (version-controlled). (Regulation (EU) 2022/2554, Article 29)
• Register of ICT third parties supporting critical/important functions with concentration flags. (Regulation (EU) 2022/2554, Article 29)

Common exam/audit questions and hangups

Expect questions that test timing, scope, and governance:

1. “Show me the concentration assessment for this contract and prove it occurred before signature.” (Regulation (EU) 2022/2554, Article 29)
2. “How do you define and identify ‘critical or important functions’ for the trigger?” (Regulation (EU) 2022/2554, Article 29)
3. “What concentrations exist today across your critical/important functions, and what are you doing about them?” (Regulation (EU) 2022/2554, Article 29)
4. “How do you account for provider groups and subcontracting?” (Regulation (EU) 2022/2554, Article 29)
5. “Where is the decision recorded, and who can accept the risk?” (Regulation (EU) 2022/2554, Article 29)

Hangups usually come from missing dependency mapping, inconsistent triggers across business units, and mitigations that never made it into contracts or operational plans.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating Article 29 as a one-time spreadsheet exercise.
Fix: embed a hard gate in the procurement/outsourcing workflow, with required artifacts before approval. (Regulation (EU) 2022/2554, Article 29)

Mistake 2: Assessing “vendor concentration” only, ignoring geography and shared components.
Fix: use a multi-dimension checklist and require architects/ops to sign off on correlated-failure analysis. (Regulation (EU) 2022/2554, Article 29)

Mistake 3: Performing the assessment after the deal is commercially locked.
Fix: run the preliminary assessment at intake, before final vendor selection or final architecture. (Regulation (EU) 2022/2554, Article 29)

Mistake 4: No clear accountability for approvals and risk acceptance.
Fix: define RACI across ICT risk, security, procurement, legal, and business owner; require named approver for acceptance. (Regulation (EU) 2022/2554, Article 29)

Mistake 5: Evidence scattered across emails and slide decks.
Fix: store a standardized evidence pack per arrangement in your GRC system (or a controlled repository) and link it to the contract record. (Regulation (EU) 2022/2554, Article 29)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for Article 29, so you should assume supervisory scrutiny will come through routine DORA supervision, thematic reviews, or examinations rather than citation-friendly precedent. (Regulation (EU) 2022/2554, Article 29)

Risk implications are concrete: unmanaged concentration can turn an ICT incident at a single provider, region, or shared service into a multi-line business outage. Article 29 is designed to force early governance before that dependency becomes embedded in architecture and operating models. (Regulation (EU) 2022/2554, Article 29)

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Appoint an owner for concentration risk method and workflow integration (typically TPRM/outsourcing + ICT risk). (Regulation (EU) 2022/2554, Article 29)
• Define the trigger: “ICT service + supports critical/important function + new or materially changed contract.” (Regulation (EU) 2022/2554, Article 29)
• Publish a one-page assessment template and approval workflow, including minimum evidence list. (Regulation (EU) 2022/2554, Article 29)
• Pilot on the next in-flight sourcing decision to prove timing works before signature. (Regulation (EU) 2022/2554, Article 29)

Days 31–60 (Near-term)

• Build the initial dependency map for critical/important functions (start with top functions first, expand iteratively). (Regulation (EU) 2022/2554, Article 29)
• Create a concentration register view: provider group, regions, shared services, and known upstream dependencies. (Regulation (EU) 2022/2554, Article 29)
• Train procurement, legal, and tech owners on the gate and what “good evidence” looks like. (Regulation (EU) 2022/2554, Article 29)

Days 61–90 (Operationalize)

• Run the assessment across your pipeline of renewals and upcoming material changes for critical/important functions. (Regulation (EU) 2022/2554, Article 29)
• Establish escalation thresholds and risk acceptance authority with documented governance. (Regulation (EU) 2022/2554, Article 29)
• Test retrieval: pick a contract and produce the full evidence pack within a short internal SLA. (Regulation (EU) 2022/2554, Article 29)

Ongoing (Business-as-usual)

• Reassess concentration when architecture or dependency changes materially, not only at contract events. (Regulation (EU) 2022/2554, Article 29)
• Keep methodology versioned and track decisions consistently across business units. (Regulation (EU) 2022/2554, Article 29)

Frequently Asked Questions

What counts as “preliminary” for Article 29?

It must happen before you conclude the contract and be decision-grade: identify concentration concerns and record how they affected approval or contract conditions. The assessment can be refined later, but you need evidence of early governance. (Regulation (EU) 2022/2554, Article 29)

Does Article 29 apply to every third party ICT contract?

No. The trigger in the text is ICT services supporting critical or important functions, assessed in the Article 28(4)(c) risk process. Keep a clear classification method so you can show why a contract is in or out of scope. (Regulation (EU) 2022/2554, Article 29)

We already do vendor risk assessments. What must change?

Add an entity-level concentration lens and make it a pre-signature gate for in-scope contracts. Standard vendor due diligence often misses correlated failure across regions, shared services, and provider groups. (Regulation (EU) 2022/2554, Article 29)

How do we handle subcontractors when we have limited visibility?

Document what you know from due diligence and what you do not know, then treat unknown critical upstream dependencies as a risk to be mitigated through contractual commitments, assurance, or architecture choices. Keep the rationale in the assessment record. (Regulation (EU) 2022/2554, Article 29)

What evidence will an auditor ask for first?

They usually start with a sampled in-scope contract and ask for proof of timing (dated assessment before signature), the dependency map inputs, the approval decision, and implemented mitigations. If you cannot produce a cohesive pack, you will spend weeks reconstructing it. (Regulation (EU) 2022/2554, Article 29)

Can we accept concentration risk if the business insists on a single provider?

Yes, but treat it as explicit risk acceptance with clear accountability, documented rationale, and compensating controls (exit planning, resilience design, contractual support). Silence or informal email approvals are the failure mode. (Regulation (EU) 2022/2554, Article 29)

Footnotes

1. Regulation (EU) 2022/2554, Article 29