The Concentration Risk Calculator: Measuring Your Cloud Dependency with HHI

You Cannot Manage What You Cannot Measure

DORA Article 29 requires financial entities to assess concentration risk in their ICT third-party arrangements. The text is unambiguous: when concluding or renewing contractual arrangements for ICT services supporting critical or important functions, institutions must consider whether the arrangement would lead to concentration on a non-substitutable provider, create multiple dependencies on a single provider or closely linked providers, or deepen reliance on a provider on which other financial entities also depend.

The requirement is clear. The methodology is not.

Most institutions today assess concentration risk qualitatively: high, medium, low. A CISO reviews the vendor register, notes that "several critical services run on AWS," and rates concentration as "medium — under monitoring." This approach satisfies no one. It provides neither the board with a quantified risk exposure, nor the regulator with evidence of rigorous assessment, nor the risk function with a basis for comparing scenarios and tracking trends.

The Herfindahl-Hirschman Index (HHI) offers a better path. Developed for antitrust economics and used by the US Department of Justice and the European Commission to evaluate market concentration, the HHI is a mathematically rigorous, widely understood, and operationally practical metric for quantifying ICT provider concentration.

The HHI: How It Works

The HHI is calculated by summing the squares of each provider's market share (expressed as a percentage) within a defined market. In antitrust, the "market" is a product or service market. For DORA concentration risk, the "market" is your institution's ICT service portfolio.

Formula: HHI = S1^2 + S2^2 + S3^2 + ... + Sn^2

Where S is each provider's percentage share of your ICT service portfolio.

Interpretation Thresholds

A perfectly diversified portfolio with 10 equal providers would have an HHI of 1,000 (10 x 10^2). A portfolio with a single provider would have an HHI of 10,000 (100^2). Real-world financial institution portfolios typically fall between 2,000 and 6,000 — solidly in the high to very high concentration range.

Figure 1: The six-step HHI concentration risk assessment process. Step 4 (identifying single points of failure) is critical — HHI alone can mask specific vulnerabilities.

Step 1: Define Your ICT Service Portfolio

Before calculating HHI, you must define what you are measuring. The most common mistake is measuring the wrong thing — counting vendor contracts rather than assessing service dependency.

The Service Portfolio Inventory

Map every ICT service that supports a business function, then assign each service to the primary provider responsible for its availability. A "service" in this context is a discrete ICT capability that, if unavailable, would affect a business function.

Example portfolio for a mid-size European bank:

This inventory reveals something that a simple vendor count obscures: while the bank has 10 different "vendors," the actual cloud provider concentration is heavily skewed toward AWS (directly and through sub-outsourcing).

Figure 2: Actual cloud provider dependency for a mid-size European bank. While 10 vendors appear in the contract register, the true infrastructure concentration shows 60% AWS ecosystem dependency (including sub-outsourcing).

Step 2: Calculate Raw HHI

Assign each service's provider share based on the number of services.

Raw calculation (service count method):

• AWS (direct): 3 services = 30%
• AWS (via sub-outsourcing: Stripe, fraud vendor, Salesforce): 3 services = 30%
• Total AWS ecosystem: 60%
• Microsoft/Azure: 3 services (Azure AD, M365, SAP on Azure) = 30%
• Google: 1 service = 10%

Raw HHI = 60^2 + 30^2 + 10^2 = 3,600 + 900 + 100 = 4,600

This places the bank in the "high concentration" range. But the raw HHI understates the actual risk because it treats all services as equal.

Step 3: Apply Criticality Weighting

Not all services carry equal risk. A critical service — one whose failure would breach the institution's impact tolerance threshold — should carry more weight in the concentration calculation than a standard service.

Criticality Weighting Matrix

Weighted calculation:

Total weighted units: 3+3+3+3+2+2+1+1+2+2 = 22

Weighted shares:

• AWS ecosystem: (3+3+3+2+1)/22 = 12/22 = 54.5%
• Microsoft/Azure ecosystem: (3+2+1+2)/22 = 8/22 = 36.4%
• Google: 2/22 = 9.1%

Weighted HHI = 54.5^2 + 36.4^2 + 9.1^2 = 2,970 + 1,325 + 83 = 4,378

The criticality-weighted HHI (4,378) is slightly lower than the raw HHI (4,600) in this example because the bank's critical services are somewhat distributed between AWS and Azure. But both calculations place the bank firmly in "high concentration" territory.

Step 4: Identify Single Points of Failure

HHI measures aggregate concentration but can mask specific vulnerabilities. A bank with an HHI of 2,000 (moderate) might still have a catastrophic single point of failure if its only payment processing capability runs on one provider with no failover.

Single-point-of-failure analysis checklist:

1. Sole-source critical services: Any critical function supported by exactly one provider with no identified alternative. Your exit strategy credibility depends on addressing these. In the example above, payment processing via Stripe (on AWS) is a sole-source critical dependency.

1. Correlated sub-outsourcing: Direct vendors that share the same underlying infrastructure. The example bank's "three AWS vendors" (Stripe, fraud vendor, Salesforce) all fail simultaneously if AWS fails — even though the vendor register shows three separate providers.

1. Geographic concentration: Services concentrated in a single cloud region or availability zone. If the bank's AWS services all run in eu-west-1 (Ireland), a regional incident takes down all AWS-dependent services simultaneously.

1. Technology monoculture: Dependencies on a single database engine, container platform, or middleware layer across multiple applications.

Step 5: Model Diversification Scenarios

The value of HHI becomes clear when you model the impact of diversification investments.

Scenario Comparison

The analysis reveals diminishing returns. Moving from the current state (HHI 4,378) to Scenario B (HHI 3,215) — by adding a secondary payment processing path — delivers the largest risk reduction per euro invested. Pursuing "perfect" diversification (Scenario C or target state) requires exponentially more investment for incrementally less risk reduction.

This is precisely the type of analysis that Art. 29 was designed to drive: quantified, scenario-based, and investment-informed.

Step 6: Establish Monitoring and Reporting

Concentration is not static. Every new service adoption, vendor consolidation, or sub-outsourcing change alters the HHI. Effective concentration risk management requires continuous monitoring.

Quarterly concentration report to the management body should include:

1. Current HHI (raw and criticality-weighted)
2. HHI trend over prior 4 quarters
3. Single points of failure count (with change from prior quarter)
4. Diversification initiative progress
5. Upcoming vendor decisions that will affect concentration
6. Sub-outsourcing changes reported by critical providers

Trigger Thresholds for Escalation

Common Pitfalls in Concentration Measurement

Measuring vendor count, not dependency depth. An institution with 50 vendors and an HHI of 5,000 is more concentrated than one with 10 vendors and an HHI of 1,500. Counting vendors provides false comfort.

Ignoring sub-outsourcing chains. Your three SaaS vendors that all run on AWS are not three independent dependencies — they are one dependency with three contractual relationships. Map the infrastructure layer, not just the contract layer.

Treating all services equally. Raw service-count HHI understates the risk from critical service concentration and overstates the impact of non-critical service diversification. Always apply criticality weighting.

Static assessment. A point-in-time HHI calculated annually for regulatory compliance provides limited value. Concentration changes with every procurement decision. Build continuous measurement into vendor lifecycle management.

Confusing multi-region with multi-cloud. Deploying across multiple AWS regions reduces geographic concentration within AWS but does not reduce provider concentration. Multi-region is necessary but insufficient for Art. 29 purposes.

From Measurement to Action

The HHI framework transforms concentration risk from a qualitative judgment into a quantified, trend-trackable, scenario-modelable metric. This enables three capabilities that qualitative assessment cannot provide:

Board-ready reporting. "Our cloud HHI is 4,378 — high concentration, driven by 54.5% AWS ecosystem dependency" is more informative and actionable than "our cloud concentration is medium-high."

Investment prioritization. Scenario modeling shows which diversification investments deliver the most risk reduction per euro. This enables the CTO and CISO to make evidence-based cases for infrastructure investment.

Supervisory preparedness. When the NCA asks how you assess concentration risk under Art. 29, producing a criticality-weighted HHI with trend data, scenario analysis, and monitoring triggers demonstrates a level of rigor that qualitative assessments cannot match.

The 15 companies that control 62% of the global technology market are not going to become 150 companies. The three hyperscalers that dominate cloud infrastructure are not going to become thirty. Concentration is a structural feature of the technology market, not a transient condition. DORA Article 29 does not require institutions to eliminate concentration — it requires them to understand it, measure it, manage it, and govern it. The HHI framework is how you do that.

---

This guide reflects DORA Regulation (EU) 2022/2554 Article 29 requirements. HHI thresholds are adapted from antitrust economics and applied to ICT concentration; regulatory supervisory thresholds for ICT concentration are subject to ongoing ESA guidance.

---