Your support platform, document service and internal assistant may be different suppliers but depend on the same cloud region or model API. Their individual reviews will not tell you what happens when that shared dependency fails. Concentration risk becomes useful to assess when it is connected to the business functions that could stop together.
Map the service behind the supplier
A common provider is a reason to investigate, not proof that every dependent service will fail at once. Region, service architecture, capacity and fallback arrangements matter. Two vendors using the same cloud may have different exposure; two vendors using different clouds may still call the same model service.
The European Supervisory Authorities designated the first critical ICT third-party providers under DORA on 18 November 2025. This concerns ICT dependencies in the financial sector and considers systemic importance and substitutability. It is not a list of AI model vendors or a certification that a designated provider is safe. ESAs designation announcement.
Shared providers can create common failure paths. The affected functions depend on the specific services, regions and recovery arrangements involved.
A vendor review needs a dependency view
A questionnaire and SOC 2 review can help assess an individual supplier. To understand concentration, connect that supplier to the services it relies on and the business operations it supports. An inventory of company names is a starting point, but it is too coarse to describe an outage.
Consider three AI features that use the same model endpoint. One can queue work, one can use a tested alternative, and one must stop. The common dependency is real, but the consequences differ. Record the service, the function and the fallback rather than assigning every vendor the same concentration score.
The important question is which operations could be impaired together, for how long, and with what practical alternatives. Provider counts can help identify where to investigate. They cannot answer that question alone.
A shared dependency can spread an incident
AWS’s account of the 20 October 2025 disruption identifies the DynamoDB DNS management system as the trigger. The useful lesson for buyers is to ask which supporting components their services need and how they behave when those components fail. The effect cannot be inferred from the cloud provider’s name alone. AWS’s incident report.
Test the shared failure, not just each supplier
Use DORA’s scope accurately
DORA requires in-scope financial entities to maintain a register of information about ICT contractual arrangements and assess concentration risk. Reporting obligations and submission instructions must be read with the applicable supervisory requirements. This is not a universal annual xBRL-CSV filing obligation for every company buying AI. DORA, Articles 28 and 29.
The same dependency analysis can be useful outside the financial sector without implying that DORA applies. For an AI feature, identify the model service, hosting, tools and data stores needed to deliver it. Then relate those dependencies to the risk assessment method your organization uses.
A direct supplier’s recovery plan may depend on a provider you also use elsewhere. Ask which shared services the recovery procedure itself requires.
Build a map you can test
Describe the dependencies
Ask critical suppliers for the relevant architecture. Identify cloud services, regions, identity services and subprocessors that support your use. Record unanswered questions explicitly.
Connect dependencies to business functions. Record which process relies on each service, its recovery objective and whether a manual alternative can carry the required workload.
Identify important overlaps. Prioritize shared dependencies by criticality, exposure and substitutability, rather than choosing the provider with the highest vendor count.
Include AI services. Record model APIs, tool services and data stores. Clarify whether a proposed fallback actually uses a different dependency.
Test the response
Define tolerable interruption. Agree how long each function can be unavailable and what degraded operation is acceptable. Use those limits to evaluate concentration.
Check the recovery plan. Ask about alternate capacity, data synchronization, access, approvals and the date of the last relevant test. A multi-region label is not the test result.
Exercise a common outage. Temporarily assume the shared dependency is unavailable. Track queued work, retry behavior, duplicate-action prevention and the restoration of normal service.
Keep the map current. Review changes in subprocessors, deployment regions, model services and fallback arrangements. A regulatory designation is useful context, not evidence that your own architecture changed.
Measure the consequence of concentration
Twenty low-impact services sharing a provider may matter less than two critical operations that cannot recover independently. The assessment should show which functions stop, what can continue and how recovery was tested. That gives the business a basis for accepting concentration or paying to reduce it.
Explore Zania’s third-party risk management →
Sources:
Share
