IT vendor management is one of the most overlooked disciplines in service management, yet a poorly governed supplier can bring down a critical service just as surely as a hardware failure. This guide walks you through how to build a structured vendor management process, what to track, how to connect supplier performance to your SLAs, and how ITSM tooling makes the whole thing sustainable.
Why IT Vendor Management Breaks Down in Practice
Most IT teams manage vendors informally. Contracts live in someone's email. Renewal dates get missed. When a third-party outage causes an incident, nobody can find the escalation contact. This is not a people problem — it is a process problem.
Vendor management fails for a few common reasons:
- Contracts and SLA commitments are stored in silos, not in a central register
- No single owner is accountable for each supplier relationship
- Performance is only reviewed when something goes wrong
- Procurement, IT operations and the service desk operate independently with no shared view of supplier data
- Renewal cycles creep up without any evaluation of whether the contract still fits the need
The result is that organisations pay for services they do not fully use, accept underperformance without challenging it, and carry hidden risk every time a critical vendor has an issue.
ITIL v4 addresses this through the Supplier Management practice, which treats vendors as contributors to value streams rather than just cost lines. The principle is simple: if a supplier affects the quality of a service you deliver, that supplier needs to be governed with the same rigour as your internal processes.
Building a Vendor Register That Actually Gets Used
The foundation of any vendor management programme is a central register of all your IT suppliers. This sounds obvious, but many organisations have never produced a complete list.
Your vendor register should capture, at minimum:
- Supplier name and primary contact details
- Category of service provided (hardware, software, cloud, managed service, connectivity, support)
- Contract start and end dates
- Contracted SLAs or OLAs (operational level agreements)
- Spend tier or criticality rating
- Owner within your IT team
- Links to contracts and supporting documentation
Categorising Suppliers by Criticality
Not every vendor deserves the same level of oversight. A common approach is to segment suppliers into tiers:
- Strategic suppliers: directly affect service delivery or business continuity, require regular executive-level review
- Tactical suppliers: important but replaceable with reasonable effort, reviewed quarterly
- Commodity suppliers: low risk, low differentiation, reviewed annually or at renewal
Criticality should be based on the impact of supplier failure, not just spend. A low-cost DNS or authentication provider that every user depends on is strategic, even if the invoice is modest.
Defining and Tracking Supplier SLAs
If your contracts include SLA commitments from suppliers — and they should — those commitments need to be tracked with the same discipline you apply to internal service targets.
Key metrics to capture for each supplier:
- Availability or uptime commitments
- Incident response and resolution times for supplier-side issues
- Change notification lead times
- Scheduled maintenance windows and advance notice requirements
- Reporting frequency and format
Connecting Supplier SLAs to Your Internal SLAs
This is where many teams miss the link. If your service desk commits to a four-hour resolution time for a category of incident, and that incident type depends on a third-party vendor, your internal SLA is only achievable if the vendor's OLA sits inside that window.
Map your underpinning contracts (UCs) and OLAs to the relevant service level agreements. When a breach occurs, you need to know immediately whether the root cause sits inside your team or with a supplier. Without that mapping, you cannot hold suppliers accountable and you cannot have an honest conversation with the business about where the delay originated.
Our post on SLA management in ITSM covers the mechanics of setting and tracking targets in more detail — the same principles apply when the target is owned by a third party.
Running Supplier Reviews That Drive Improvement
A vendor register and a contract are just paperwork until you build a review cadence around them. Regular supplier reviews serve two purposes: they keep suppliers accountable and they give you early warning of relationship or performance issues before they become incidents.
For strategic suppliers, most experts recommend a formal monthly or quarterly review. For tactical suppliers, a quarterly or semi-annual review is usually sufficient. Commodity suppliers can be reviewed at renewal.
A structured review agenda typically covers:
- Performance against contracted SLAs over the review period
- Open incidents or problems caused or contributed to by the supplier
- Upcoming changes, releases or maintenance from the supplier side
- Risks flagged by either party
- Actions from the previous review and their status
- Forward look: upcoming renewals, scope changes or new requirements
What Good Looks Like
A good supplier review is not a blame session and it is not a rubber stamp. It is a structured conversation where both sides bring data. You should leave each review with a small number of clear actions, owners and deadlines. If a supplier is consistently underperforming, the review record becomes the evidence base for contract renegotiation or exit.
Document every review. If a dispute arises at renewal or during a major incident, that documentation is invaluable.
Integrating Vendor Management with Incident and Change Processes
Vendor management does not live in isolation. Two ITSM processes in particular need tight integration with your supplier data: incident management and change management.
Vendor-Caused Incidents
When an incident is logged and the likely cause is a third-party service, your incident record should capture the supplier involved. This lets you:
- Route the incident to the correct resolver group with supplier context
- Trigger the supplier's own SLA clock at the right moment
- Track supplier-caused incidents over time to identify patterns
- Feed data into problem management investigations
Without this link, supplier-caused incidents get absorbed into your general incident statistics and the underlying pattern is invisible.
Supplier Changes and the CAB
Suppliers make changes too. Unplanned or poorly communicated supplier changes are a common cause of incidents. Your change management process should require that significant supplier changes — infrastructure upgrades, API changes, certificate renewals, major version updates — are raised as change requests and reviewed by your Change Advisory Board or at least by a change manager.
Our post on the IT Change Advisory Board covers how to structure CAB governance for both internal and supplier-driven changes.
A Practical Vendor Management Checklist
Use this checklist to assess the maturity of your current vendor management process and identify gaps:
Vendor register and governance:
- All IT suppliers are listed in a single, maintained register
- Each supplier has a named internal owner
- Suppliers are categorised by criticality tier
- Contract start, end and renewal dates are tracked with automated reminders
Contract and SLA management:
- All contracts are stored centrally and accessible to relevant stakeholders
- Supplier SLAs and OLAs are documented and mapped to internal service targets
- Breach notification and escalation paths are defined in each contract
- Penalty and remedy clauses are understood and tracked
Performance and review:
- A review cadence is scheduled for each supplier tier
- Review meetings follow a structured agenda and produce documented actions
- Supplier performance data is pulled from ITSM incident and problem records
- Trends in supplier-caused incidents are reviewed at least quarterly
Risk and compliance:
- Supplier risk is assessed at onboarding and reviewed annually
- Data processing agreements and compliance obligations are documented
- Exit plans exist for strategic and high-risk suppliers
- Supplier financial health is monitored for strategic vendors
Integration with ITSM:
- Incidents linked to supplier issues are tagged with the relevant supplier
- Supplier changes are raised through the change management process
- Supplier contacts are available in the ITSM platform for rapid escalation during incidents
Key Takeaways
Effective IT vendor management is a discipline, not a one-off task. The organisations that do it well share a few habits: they maintain a live, categorised supplier register; they map supplier commitments to internal service targets; they review performance on a scheduled cadence rather than reactively; and they integrate supplier data into incident, problem and change workflows.
The payoff is real. You reduce the risk of supplier-caused outages catching you off guard, you have the data to hold suppliers accountable at renewal, and your service desk has the context it needs to resolve supplier-linked incidents faster.
Key points to carry forward:
- Build a vendor register before anything else — you cannot manage what you have not listed
- Tier your suppliers by criticality, not just spend
- Map underpinning contracts to internal SLAs so breaches can be attributed accurately
- Run structured reviews on a fixed cadence and document every action
- Tag supplier-caused incidents in your ITSM platform to surface patterns over time
- Treat supplier changes as change requests subject to the same governance as internal changes
The TIKTING service management platform supports supplier management natively, allowing you to maintain your vendor register, link suppliers to configuration items, associate incidents with third-party causes, and track OLAs alongside internal SLA targets — all within a single ITIL v4-aligned workspace. Odysseus asset discovery adds a further layer by surfacing the hardware and software assets underpinned by each supplier relationship, giving you a clearer picture of supplier dependency across your environment.
