One Supplier, No Fallback: Tackling Concentration Risk in Your SME’s IT Supply Chain

One supplier can make IT simpler to manage. It can also become the quiet dependency behind your phones, cloud applications, user accounts, backups and support desk.

That does not mean every business needs a different supplier for every service. It means directors need to understand what would happen if a key provider became unavailable, lost access to a critical system, suffered a serious incident or could no longer trade. If the answer is “we would have to wait and see”, the business has a concentration risk to manage.

This is first a governance and strategy issue, not a procurement exercise. The role of a Fractal IT Director is to map the dependencies, assess the business impact and set a practical resilience and exit strategy. Specialist suppliers and services can then help put that strategy into effect.

How a supplier becomes a single point of failure

Concentration risk is easy to miss because it rarely appears on one invoice. It builds up as services are connected over time.

A managed service provider might administer user accounts, devices, network access, cloud services and backups. A single connectivity provider might supply the office internet connection and the voice service that depends on it. A cloud platform may host business applications, identity, files and the tools used to manage them.

Each arrangement may be reasonable on its own. The risk comes from their shared dependencies. If one provider, account or connection is unavailable, several parts of the business can fail together.

Supplier lists alone will not expose that. The National Cyber Security Centre’s supply-chain guidance recommends understanding suppliers, prioritising those that matter most and identifying relevant subcontractors. For an SME, that means mapping what supports important business services, not just recording who sends the bills.

Start with the business service, not the supplier

Begin with the business activities that must continue: taking payments, booking appointments, processing orders, communicating with customers or accessing essential records. Then trace the people, systems and suppliers that each activity relies on.

For example, a customer-service team may need working devices, identity access, a cloud application, a stable connection and business telephony. If any one of those has no workable fallback, the whole service could be affected.

A useful dependency map records:

• The business service and its accountable owner.
• The systems, data, identities, devices and connections it depends on.
• The suppliers involved, including important subcontractors where known.
• Shared dependencies, such as administrator accounts, cloud tenants, network routes or backup platforms.
• The likely impact of an interruption over one hour, one day and several days.
• Recovery requirements, contract dates, notice periods and exit arrangements.

David’s practitioner-led perspective draws on Google-certified IT project management, multi-national onboarding and hands-on systems administration. That experience helps keep the discussion grounded in how services actually work together, rather than how they look in a contract register.

The objective is not to eliminate every dependency. It is to make important dependencies visible, decide which ones the business is prepared to accept and put sensible controls around the rest.

Decide where concentration is acceptable

A single supplier can offer genuine advantages: simpler accountability, integrated services and less work coordinating multiple providers. The trade-off is that a disruption or dispute may affect more of the business at once.

That is a business decision. Ask what the supplier provides, what operational burden it removes and what the cost would be if the service stopped. Then compare that value with realistic alternatives, including a secondary route, an independent backup or a documented manual process.

Cloud services are a good example. A second cloud platform is not automatically safer or better value. It can introduce extra cost, complexity and security work. The UK Government’s guidance on managing technical lock-in in the cloud recommends weighing the value a service provides against the practical cost and time of switching. It also advises organisations to keep their cloud portfolio under review.

For Cloud Solutions, the question is therefore not simply “Can we move everything tomorrow?” A more useful question is “If we had to change course, what would it take, how long would it take, and which services would need a different route first?”

Make the contract support resilience and exit

An exit plan is only useful if it is possible to carry out. Review supplier agreements for the practical details, not just the headline service level.

Check whether the contract sets out:

• How incidents are reported and how quickly the supplier must notify you.
• What support, recovery and service restoration commitments apply.
• Whether subcontractors are involved and how changes to them are communicated.
• Who controls administrator accounts, domains, configurations, encryption keys and recovery credentials.
• How you can obtain your data, records, configurations and documentation in a usable format.
• What transition assistance is available, how long it lasts and what it costs.
• How your information is returned or securely deleted when the service ends.

A service-level agreement can provide remedies after an outage, but it does not prevent the outage. The NCSC’s cloud resilience guidance stresses that availability commitments must suit business needs and that resilience depends on the service design. Redundancy and failover need to be configured and tested; they should not be assumed.

Build a fallback that works in practice

Resilience is not the same as buying a duplicate of everything. It is a proportionate ability to keep critical work moving or recover it within an acceptable time.

For a business reliant on one internet connection, a separately delivered 4G or 5G connection may offer a practical alternative, subject to coverage and testing. For telephony, check how staff and customers would communicate if the main connection or voice service failed. For cloud applications, establish how data can be restored and who can access recovery tools if the usual administrator is unavailable.

Keep critical recovery access independent of the supplier or service it is intended to recover. If the same account, network or provider controls both the live environment and its fallback, a single incident may affect both.

Test one realistic scenario at a time. For instance: the primary connection is down, the supplier is unreachable, or administrators cannot access the cloud tenant. Can staff switch to the alternative? Are the necessary details available? Who makes the decision, and who tells customers? A short exercise often reveals a missing password, unclear responsibility or contract assumption before an actual incident does.

Use bolt-on services to deliver the strategy

Once priorities and dependencies are clear, execution can be assigned to the right people. Managed IT Services, Helpdesk Support, Network Solutions, Cloud Solutions and Voice and Connectivity can all support a resilience plan, but they are implementation and support services, not a substitute for the plan itself.

A consultancy-first review should establish which services need stronger recovery, where independent connectivity is worthwhile and which supplier responsibilities need clarifying. A trusted network of specialist channel partners can then provide specific technical delivery where appropriate, while strategic oversight keeps the work aligned to business priorities.

Technology Expense Management (TEM) is also part of concentration-risk governance. Reviewing supplier costs, usage, renewal terms and overlapping services can show where the business is financially dependent on one provider and where commitments limit its options. The aim is not to chase the lowest price. It is to understand the cost of resilience, avoid paying for unused capacity and retain meaningful choice at renewal.

David’s approach is to lead with strategy and use execution services to support it. Where relevant to a wider technology plan, areas such as Disaster Recovery or a Dynamics 365 Jump Start can be assessed against the business’s real operational requirements, rather than introduced as disconnected purchases.

A practical first review

Start with the five services whose interruption would cause the greatest operational or customer impact. For each, identify the suppliers and shared technical dependencies. Then ask:

1. What would stop working if this supplier were unavailable?
2. Could another critical service fail at the same time because it shares an account, connection or platform?
3. Who controls access, data and recovery arrangements?
4. How long would a replacement or workaround take, and what would it cost?
5. When is the next contract decision, and what notice period applies?
6. Has the proposed fallback been tested by the people who would use it?

Assign an owner to each action and revisit the map when services, suppliers or business priorities change. This is a manageable governance discipline, not a one-off paperwork exercise.

One supplier may still be the right choice. The important distinction is between deliberate reliance and accidental dependence. When directors can see the exposure, understand the trade-offs and test a realistic way out, supplier concentration becomes a managed decision rather than a surprise.

For a conversation about mapping your dependencies and setting priorities, talk to the consultancy team. To explore the wider Evestaff group of services, visit evestaff.co.uk.

SEO keywords: Cloud Solutions, Disaster Recovery, Dynamics 365 Jump Start, Helpdesk Support, IBM i Management, Managed IT Services, Network Solutions, Technology Expense Management, Voice and Connectivity