ICT supplier risk guide for UK SMEs

The ICT supplier risk facing UK SMEs

ICT supplier risk management for UK SMEs means controlling the operational, security and data risks created by cloud platforms, SaaS tools, managed service providers and other technology suppliers. A proportionate review connects each service to the business work it supports, the evidence available and the person responsible for deciding what remains acceptable.

The NCSC's supply chain principles recommend understanding suppliers, subcontractors, information access and the parts of the service you rely on, then using proportionate risk assessment and documented decisions. NCSC: understand the risks.

Start with one important supplier and one service. Record what information and access it receives, what would happen if it failed, and what you would need to continue or move elsewhere. Keep unknowns visible rather than treating an unanswered questionnaire as reassurance.

This guide focuses specifically on UK SME technology suppliers and lean teams. For the broader programme covering every third party, including tiering, contracts, continuous monitoring and board reporting, read the third party vendor risk management guide.

Why ICT supplier risk is different from general procurement risk

Data handling. A technology supplier may store or process customer records, financial information or intellectual property. Review the information involved, its location, access, retention and exit arrangements against the service you actually use.

Shared infrastructure and security dependencies. A cloud platform, software integration or managed provider can connect your business to systems operated by others. Identify the permissions and dependencies involved, including where several services rely on the same underlying provider.

Service continuity. Ask which business tasks stop if the supplier is unavailable and how long an agreed workaround would remain usable. Do not assume a service is easy to replace because it appears to be a commodity purchase.

Access and accountability. Establish who grants and reviews supplier access, who receives incident notifications and who can make decisions during disruption. A contract owner and a technical owner may have different responsibilities; record both.

Building an ICT supplier risk assessment framework

Step 1: map your ICT supplier portfolio

Start with a simple inventory. For each ICT supplier, capture:

• The supplier, service and technology provided.
• The business tasks that depend on that service.
• The type and sensitivity of information held or processed.
• The technical access the supplier has to your systems.
• The contract owner and technical contact within your organisation.
• Known dependencies, renewal dates and exit arrangements.

Map criticality to your actual workflow. Broadband used for essential calls and transactions may be as consequential as a hosted business application. Assess disruption, alternatives and recovery evidence rather than assigning importance from the product category alone.

Step 2: assess relevant risk dimensions

Security controls. Ask how access, updates, vulnerabilities and incidents are managed for the service. Where the supplier provides a certificate, assurance report or test summary, check its scope, date, exclusions and relevance. Receiving a document is not the same as establishing that it answers your question.

Service viability. Consider how the relationship would continue through staffing, ownership or financial changes. Ask what support, records and access your business would need if the provider could no longer deliver. Do not treat a filing or a reassuring response as a guarantee of future operation.

Data handling. Identify the information, processing purposes, locations, retention and deletion arrangements. Establish the parties' roles before deciding which contractual requirements apply; not every supplier handling personal information has the same role.

Resilience and continuity. Request the recovery arrangements and available test evidence relevant to your service. Ask what incidents are communicated, to whom, and how your team would act on that information.

Contract and exit. Read the proposed service commitments, responsibilities, costs and termination arrangements. Record unclear terms for clarification with the appropriate commercial or legal adviser.

Step 3: classify and prioritise

Use a small set of tiers to organise attention. The following categories are a suggested approach, not a certification scheme or mandatory review schedule.

• Critical suppliers: disruption, sensitive information or privileged access creates consequences that need close assessment and a clear contingency plan.
• Important suppliers: the service supports significant work, with documented alternatives or workarounds to assess.
• Lower-risk suppliers: limited access and business impact support a lighter review, provided those assumptions are recorded and remain valid.

For each tier, agree review dates and event triggers based on the actual exposure, contract and requirements. Reassess when the service, its access or your business use changes. Use the tier to set the next review action and keep unanswered questions visible.

Record material supplier exposure alongside other technology risks using this practical IT risk management process for SMEs, so supplier weaknesses compete for attention on the same basis as internal risks.

Step 4: complete a supplier evidence and decision record

A useful review records the evidence you have seen, what it supports and the decision your business needs to make. This worksheet is a practical review aid, not a legal assessment or a certification checklist.

Start with one supplier and one service. If a supplier provides several services, check whether a document covers each relevant service before reusing its answer.

Mark an area not applicable only with an explanation. For every material question, copy these fields into your review record:

• Supplier and service: ___
• Review question and reason it matters: ___
• Evidence document or link, version and date: ___
• Date reviewed and reviewer: ___
• Supplier response: ___
• What the evidence supports: ___
• What remains unknown or out of scope: ___
• Decision and business decision owner: ___
• Follow-up action, action owner and due date: ___
• Next review date or trigger: ___

Store confidential supplier documents in an appropriate restricted location. The record can point there instead of copying sensitive material into a widely shared file.

Here is an illustrative entry, not a client result:

Receiving a document does not establish that a requirement is met. Read what it covers and whether it addresses your actual service. If you cannot assess it, name the person who will help resolve that limitation.

Close with a clear decision: proceed, proceed with agreed actions, defer pending evidence, or consider another option. Record who decided, why, and who owns each open action.

Key ICT supplier risks to monitor

Concentration risk

Look for several business services relying on the same platform, identity provider or managed partner. Ask which workflows would be affected together and whether the proposed fallback shares the same dependency.

Document the relationship rather than assuming several supplier names mean independent services. Test the relevant continuity arrangements with the people who would use them.

Access and authentication risk

For each supplier connection or account, ask:

• What access is required for the agreed service?
• Who approves it and reviews whether it is still needed?
• Which authentication and logging controls apply?
• Can routine support use time-limited access where appropriate?
• Who removes access when staff or the engagement changes?

Discuss multi-factor authentication, privileged access and audit records with the technical owner. Record any limitation and the resulting risk decision instead of implying every supplier system supports the same controls.

Subcontractor and service-dependency risk

Ask significant suppliers which other providers support the service, what those providers do and how relevant changes or incidents are communicated. Distinguish operational dependencies from the specific data-protection role of a sub-processor.

A dependency failure may affect your workflow even when you have no direct contract with that provider. Record who obtains information and who decides whether the remaining uncertainty is acceptable.

Data portability and exit risk

Before committing, establish which records can be exported, in which formats, with what assistance, timescales and costs. Ask how your team would verify that an export is usable and what would happen to remaining copies.

Use a suitable test where possible. An available export button does not establish that all the information needed by the next system will transfer correctly. Record unresolved gaps in the supplier decision.

Practical ICT supplier risk management

Connect contracts to the evidence

Discuss service commitments, incident communications, assistance, exit and responsibility for changes alongside the assessment findings. Record what the contract actually provides and where further advice or negotiation is needed. Do not assume a standard term can be changed or that a clause proves a control operates effectively.

Where your organisation is a controller using a processor, the ICO's guidance describes assessing sufficient guarantees proportionate to the processing and risk, using a contract and documented instructions, and monitoring the relationship. The ICO flags this guidance as under review following the Data (Use and Access) Act; check the current guidance and your circumstances when settling requirements. ICO: responsibilities for controllers using a processor.

Ask focused questions

Choose questions that address the service's material risks. Request evidence behind important answers and follow up on omissions. Avoid treating questionnaire length as a measure of assurance.

When reviewing certificates or reports, check the named organisation, covered service, dates and limitations. If the document does not answer your question, record the gap and request relevant evidence rather than treating a badge as a guarantee.

Maintain the record

Agree who follows supplier status and incident communications, reviews access and checks open actions. Set review dates appropriate to the risk and revisit the record after material changes or incidents.

At each review, record what changed, which evidence remains current and what decision is now needed. Carry forward unresolved actions with their owner rather than restarting an empty questionnaire.

Plan for supplier disruption

For critical services, document contacts, escalation routes, workarounds and recovery responsibilities. Check what can continue while the supplier investigates and which decisions need business approval.

Use a proportionate exercise to test those arrangements. Record dependencies and limits so the plan does not assume help or access that would disappear in the same incident.

Getting started

Start with the supplier inventory and select a service where disruption, data handling or access matters to your business. Complete the evidence record, identify the unresolved decisions and give each action an owner and date.

If supplier evidence is incomplete or difficult to assess, explore IT compliance consulting to discuss the review scope and decisions your business needs to make.