How should boards assess concentration risk alongside cyber resilience?

What boards should measure before calling concentration risk acceptable

Boards should treat concentration risk as a resilience problem only when they can define the dependency, the shared failure mode, and the business services affected. The useful question is not how many suppliers exist, but whether a single provider, platform, region, or integration layer can take down multiple critical services at once.

That means the assessment has to move from vendor inventory to service topology: which controls, platforms, and operational processes are shared, where substitution is realistic, and how fast the organisation can fail over. A concentration that is tolerable for a low-impact function may be unacceptable when it sits underneath revenue, customer access, or regulated operations.

Boards also need to separate correlation from diversification. Two suppliers can still fail together if they depend on the same cloud region, identity service, software update path, or managed operations team. That is why a concentration review should ask for blast-radius analysis, not just procurement counts.

Why insurance is only a partial offset

Insurance can reduce financial loss, but it rarely removes operational disruption, regulatory scrutiny, or customer harm. For board-level judgment, the real issue is how much loss remains after claims, exclusions, deductibles, delays, and reputational impact are considered.

That residual loss matters because cyber resilience is about continuity under stress, not only post-incident reimbursement. If a provider outage or compromise disables several services at once, the organisation may still face recovery costs, service credits, contractual penalties, and management time even when the policy pays out.

Current guidance from ENISA Threat Landscape and NCSC UK Advice and Guidance consistently treats third-party and supply-chain concentration as a resilience issue because the same dependency can amplify both attack impact and outage impact. Boards should therefore ask whether the insurance programme is sized to the residual impact after the worst plausible dependency failure, not the average incident.

How boards should turn concentration into a resilience decision

A useful board assessment starts with the services that matter most, then works backward to the dependencies that make them fragile. That includes identifying which vendors are truly critical, which internal controls rely on the same external platform, and which recovery paths are genuinely independent.

The strongest practical test is scenario-based: if this provider, region, or shared service fails for a day, what business functions stop, what manual workarounds exist, and how long can they be sustained? This is where concentration risk becomes measurable, because the board can compare time-to-recover, service criticality, and uninsured loss against risk appetite.

For organisations with material third-party exposure, DORA and the Cloud Controls Matrix are useful anchors for structuring that review around resilience testing, supplier dependency, and cloud governance. Where a provider concentration also creates shared access paths or shared secrets exposure, the board should also look at whether a single compromise could affect multiple connected services.

Risk and Threat Considerations

Concentration becomes risky when one provider, platform, or architecture choice creates a single point of failure across several business-critical services. The threat is not just outage, but correlated compromise, where an attacker or operational failure can spread across multiple systems before the organisation can contain it.

Failure mechanism: Shared infrastructure, shared administration, shared identity trust, or shared recovery tooling can turn one incident into a multi-service event. If the same dependency also underpins logging, authentication, or backup access, the organisation may lose both service availability and visibility at the same time.

Impact: The board may underestimate true exposure if it looks only at vendor count or insured loss. Concentration can produce extended downtime, regulatory reporting obligations, contractual penalties, and recovery costs that remain even after an insurance claim is settled.

Practitioner Guidance

What to verify: Ask management to show the specific dependencies behind each critical service, including shared cloud services, identity layers, and operations tooling. If two services fail together, they should be treated as one resilience cluster for board reporting.

Decision rule: If a concentration failure would exceed the organisation’s tolerated outage window or uninsured loss threshold, the board should require diversification, stronger exit planning, or explicit risk acceptance with a named owner.

What good looks like: The board receives a small set of scenarios with quantified blast radius, recovery time, and residual loss, rather than a generic supplier list. That gives directors a basis for deciding whether the concentration is strategically efficient or operationally fragile.

Practitioner takeaway: Concentration risk is acceptable only when the organisation can prove that shared dependencies are limited, recovery is realistic, and the uninsured residual is within appetite.

Related resources from NHI Mgmt Group

• Why does requiring cyber incident disclosure change how investors and boards assess risk?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• Why do non-human identities create audit risk in modern environments?