Boards should ask whether the organisation can stand up the same critical function on another provider tomorrow, and what the uninsured cost would be while that happens. If the answer depends on a rebuild, the renewal is not just a procurement choice. It is a resilience decision with direct enterprise risk implications.
Why concentration turns a renewal into a resilience question
Platform concentration is not just a purchasing issue because it can turn one vendor, one architecture, or one operating model into a single point of failure. Boards should care less about feature parity than about whether the organisation has exit capacity, operational substitutes, and a realistic path to continuity if the provider or platform becomes unavailable, untrusted, or commercially untenable.
A useful board question is whether the same critical function can be reconstituted on another provider within an acceptable time window, using existing evidence, contracts, data, and operating procedures. If that answer depends on a major rebuild, the renewal decision is already shaping resilience posture. The cost question should include downtime, migration labour, control revalidation, and any uninsured impact during transition. That is why concentration risk is often hidden until a change event forces the issue.
In practice, many organisations discover concentration risk only when renewal timing collides with an outage, pricing shock, or failed migration rehearsal.
How boards should test concentration before they approve renewal
The practical test is whether concentration has created a dependency the organisation cannot quickly unwind. Boards do not need to review every technical detail, but they should require management to show how the critical function would continue if the current platform had to be replaced on short notice. That includes the portability of data, integrations, identity or access dependencies, logging, support workflows, and any custom controls that make the service hard to replicate elsewhere.
For concentration to be meaningful, management should be able to answer four questions clearly: what exactly is concentrated, how quickly it could fail or be withdrawn, what would have to change to move, and what the transition would cost while the function remains exposed. If those answers are vague, the renewal is not simply preserving service, it is extending dependency. Where the platform is embedded across multiple business processes, concentration can also create correlated failure, so a single disruption can affect several services at once.
- Identify the critical function, not just the product name.
- Test whether data, configurations, and controls are portable in practice.
- Quantify transition cost, downtime, and control revalidation effort.
- Check whether the organisation has a documented fallback or dual-run option.
- Ask whether the renewal would increase exit difficulty over the next contract term.
A strong board pack should distinguish ordinary vendor dependency from concentration that would materially delay recovery, because the latter changes the enterprise risk profile. This guidance breaks down when management treats migration as a theoretical exercise instead of rehearsing the actual dependencies that would have to move.
Common concentration edge cases boards should not miss
Tighter concentration scrutiny often increases governance overhead, because the board must weigh continuity protection against cost, complexity, and delayed delivery. The trade-off becomes sharper when a platform is genuinely efficient but also hard to replace, so boards need to separate convenience from resilience.
Some concentration is accepted by design, especially where regulation, specialised functionality, or integrated operational tooling limits viable alternatives. In those cases, the board should ask whether the concentration is being actively compensated for through documented exit plans, tested backup arrangements, and control evidence that would survive a provider failure. Another common edge case is partial portability, where data can be exported but workflows, permissions, or monitoring cannot. That creates a false sense of exit readiness.
Concentration can also sit below the obvious vendor layer, in shared infrastructure, shared support processes, or a common identity and access model across several systems. Boards should treat these as correlated dependency risks when the same failure mode could affect multiple critical services at once. When a platform renewal increases lock-in faster than resilience, the decision should be escalated as an enterprise risk, not accepted as routine procurement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-04 — Risk Appetite and Risk Response | Board renewal decisions should reflect enterprise risk tolerance for vendor concentration. |
| RC.RP-01 — Recovery Plan Execution | The question asks whether the function can be stood up elsewhere quickly after disruption. | |
| ID.SC-02 — Cyber Supply Chain Risk Management Strategy | Platform concentration creates supplier dependency and exit-risk issues across the service chain. | |
| Recommendation — Set renewal approval criteria using documented risk appetite for recovery time and dependency exposure. Test whether the critical function can be restored on an alternate platform within the recovery window. Assess supplier concentration and require exit planning for critical platform dependencies. | ||
| CIS Controls v8 | 15.1 — Service Provider Management | Boards need supplier dependency, continuity, and exit assurance before renewing a concentrated platform. |
| Recommendation — Review provider concentration and require documented continuity and transition arrangements. | ||
| NIST Zero Trust (SP 800-207) | SR-5 — Resource Isolation and Segmentation | Concentration becomes more dangerous when shared services create correlated failure across critical functions. |
| Recommendation — Reduce correlated blast radius by isolating critical services and validating fallback paths. | ||
| DORA | Article 28 — ICT Third-Party Risk Management | Renewal concentration is a third-party dependency and exit-risk issue for operational resilience. |
| Recommendation — Require exit strategies and resilience testing for concentrated ICT dependencies. | ||
Practitioner Guidance
What to prioritise: Ask management to evidence exit readiness for the specific critical function, not a generic vendor offboarding story. The key judgement is whether continuity can be preserved without a redesign, because that is what separates manageable dependency from material concentration.
What to verify: Require proof of portability for the items that actually drive recovery: data export, configuration rebuild, access model, monitoring, and operational runbooks. If any of these would need to be invented during a move, the renewal is extending a resilience gap.
Decision rule: If the function cannot be restored on an alternative platform within the board’s tolerable interruption window, treat the renewal as a concentration-risk decision and demand compensating controls or a reduced term.
Practitioner takeaway: The board’s job is not to avoid concentration entirely, but to avoid renewing concentration that the organisation cannot unwind fast enough to protect continuity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
