Third party vendor risk management guide

Third party vendor risk management helps you decide whether a supplier can be trusted with a particular service, system or set of information, and what to do if that supplier fails. It connects procurement decisions with operational consequences.

Start with your most important dependencies. If a supplier reported a serious incident today, could you identify the affected service, contact its owner and contain your exposure? A register and a questionnaire are useful only when they support that decision.

The NCSC's supply-chain guidance groups the work around understanding risks, establishing control, checking arrangements and continuing improvement. The process below applies those ideas to a technology supplier portfolio without assuming a particular number of applications or a costly monitoring platform.

Build an inventory that reflects the work

Reconcile procurement and finance records with staff and system owners. Include cloud services, managed providers, contractors with access and important software dependencies. An unpaid service or a departmental subscription can still hold information or interrupt a critical process.

For each relationship, record the service, legal supplier, internal owner, data handled, access granted, business processes supported and contract dates. Record known subcontractors and locations where they matter. Keep uncertainty visible rather than marking an unanswered question as low risk.

Distinguish the supplier list from a dependency map. The list tells you who supplies you. The map shows which processes stop and whether several suppliers rely on the same identity, cloud or payment service. That shared dependency can defeat an apparently diverse set of suppliers.

Set risk tiers from actual consequences

Use a small number of tiers that your team can explain. A critical supplier might have privileged access, handle highly sensitive information or support a process with no workable alternative. An important supplier might support a substantial process with a tested workaround. A lower-risk supplier has limited access and limited disruption consequences.

Do not assign a tier solely from a product label. An HR system may hold sensitive information; a marketing platform may have broad customer-data access. Either can be more consequential than a cloud service that contains only public material.

Record why the tier was chosen and what review it triggers. The review frequency should reflect risk and change. An acquisition, serious incident, new subprocessor, material service change or expired assurance should prompt reassessment even if the next scheduled review is months away.

Ask for evidence that answers your risk question

Read any assurance report for what was examined, the exceptions and the responsibilities relevant to your use. For security certifications, check that the actual service is within scope.

For a critical dependency, ask how you can validate the evidence. You may need further questions, an independent report, contractual audit arrangements or a practical test. Not every supplier will permit unrestricted customer testing; agree authorised methods and handle sensitive assurance documents appropriately.

Separate legal obligations from contract choices

Under ICO processor-contract guidance, a controller using a processor needs the required written contract or other legal act and sufficient guarantees. Required terms include instructions, confidentiality, security, subprocessors, assistance, end-of-contract handling and audit information. Contract wording and actual operation both matter.

A processor must notify its controller of a personal data breach without undue delay. Do not replace that obligation with a negotiated 24- or 48-hour allowance that could permit avoidable delay. Agree operational escalation targets that help both parties meet their obligations, alongside the applicable legal wording and thresholds.

The NIS2 Directive is an EU framework; it is not the UK's updated NIS2 regulations. Whether it applies directly or through customer commitments needs a separate scope assessment. Financial-sector and other specialist rules also require their own applicability check. A general vendor programme does not establish compliance with every regime.

Use qualified legal input for liability, indemnities, audit rights and notification terms. Decide which terms are required, which are negotiable and which unresolved gaps management is willing to accept. Record that decision before commitment.

Test an exit before relying on it

Ask which information can be exported, in what format and by whom. Include attachments, configuration, audit history and relationships between records where they matter. A file download may not be sufficient to restart the process elsewhere.

Agree how access will be revoked and how the supplier will return or delete information at the end of the relationship, subject to lawful retention. Establish the transition support, notice, charges and timing in advance.

For resilience, test a realistic failure. If the supplier and your own identity provider are both unavailable, can you still reach contacts, recover essential information and operate a manual process? Keep sensitive fallback information protected and accessible only to authorised people.

A completed assessment of a fictional payroll supplier

A fictional 80-person business is renewing its payroll service. The assessment identifies employee and bank information, a fixed payroll deadline and no immediate replacement provider. Those facts justify a high-priority review even though the supplier has been reliable.

The owner obtains the processing terms and assurance evidence, confirms the escalation route and tests an authorised export using suitable test data. The test reveals that the export omits a field needed by the fallback process. The team assigns a repair to the supplier and changes its continuity plan to account for the limitation.

Management renews only after the required fix is demonstrated and the remaining transition risk is recorded. If the supplier cannot provide a workable export, the decision becomes whether to accept that dependency temporarily with additional controls or plan a replacement. A positive questionnaire score would not resolve the missing capability.

Monitor changes without creating an empty reporting task

Assign an internal owner to each material relationship. Review incidents, service performance, contract changes and outstanding actions. Keep a route for supplier advisories and record which systems or versions you use so an alert can be assessed promptly.

External ratings or automated alerts can prompt investigation. They do not replace knowledge of the service, contract or controls. Avoid presenting a rating as proof that your data is safe.

Use meetings where they resolve a decision. A short review of overdue critical actions may be more useful than a recurring call with no evidence or owner. Escalate when an action changes the risk you previously accepted.

Prepare for a supplier incident

Your recovery plan should identify who assesses a supplier alert, who can revoke access and who decides whether to stop a dependent process. Keep contacts available outside the affected service.

Containment can itself interrupt operations. Before disabling an integration, establish what it controls, what records need preservation and whether a safe fallback exists. The incident-management lessons provide further planning prompts.

Assess regulatory and customer notifications separately. The ICO's breach guidance distinguishes notification to the controller, regulator and affected individuals. Record the awareness time, evidence and decision rather than assuming the supplier has handled every obligation for you.

Keep access and ownership under review

Supplier staff should receive only the access required for their task, for an agreed duration where practical. Verify the identity and authority of someone requesting a change using a known route. A familiar supplier name is not enough to approve new privileges.

Make procurement, IT and business owners share the decision. Procurement owns commercial process, IT assesses technical access and dependency, and the business owner explains the operational impact. A risk without an accountable owner is unlikely to be resolved when the supplier changes.

For a narrower SME worksheet, use the ICT supplier risk management guide. Our IT management and security consulting services can help build the register, test dependencies and prioritise unresolved risks. Arrange a consultation with one critical supplier and the decision you need to make about it.