Vendor Risk Management: How to Run a Program for IT Vendors

Vendor risk management is how an organization finds, rates and controls the risks that come with its suppliers, from the request to buy until the relationship ends. For technology vendors, it means knowing who holds your data, who can reach your systems and what stops if a service fails. This guide sets out a program you can run: the steps, the contract clauses and who owns each part.

What vendor risk management is

A vendor risk management program is a repeatable way to work out what could go wrong with each supplier and what you’re doing about it. It’s also called third-party risk management, a term some organizations widen to include partners and resellers. For technology suppliers it’s one part of IT vendor management, which also covers contracts, spend, performance and renewals.

Why IT vendors carry particular risks

• Access to data and systems. A SaaS application holds your customer records. A managed service provider has administrator accounts on your network. An integration holds an API token that can read and change your data.
• Dependence on a service. If the cloud service your order process runs on goes down, orders stop, and switching providers takes a planned migration.
• The vendor’s own suppliers. Your SaaS vendor runs on someone else’s hosting and may pass your data to sub-processors. These suppliers of your supplier, often called fourth parties, bring risk you inherit, usually without a contract with them.
• Change during the contract. Vendors get acquired, add sub-processors, change terms and add AI features that use your data, so a review done at purchase goes stale.

The NIST Cybersecurity Framework (CSF) 2.0 has a category for this under its Govern function, Cybersecurity Supply Chain Risk Management. Its outcomes track the lifecycle below, from knowing your suppliers and prioritizing them by criticality to planning for what happens after an agreement ends. NIST SP 800-161 Rev. 1 goes further, with guidance on identifying, assessing and mitigating cybersecurity risks throughout the supply chain. NIST says nongovernmental organizations may use it on a voluntary basis.

The vendor risk management lifecycle

Seven steps, each scaled to the vendor’s tier.

1. Inventory every vendor

Build the list from accounts payable records, your contract repository, the applications connected to your identity provider, and corporate card and expense reports, which is where SaaS bought outside IT tends to show up. Free trials count once real data goes in.

For each vendor, record the business owner, the service, its data and access, the contract end and notice dates, and its tier. Then route every new vendor through intake, which the IT procurement guide covers, so the list stays complete.

2. Classify and tier by risk

Tiering decides how much effort each vendor gets. Look at the data it will hold, its access to your systems (from none to administrator rights or an agent on your machines), how long you could work without it and how hard it would be to replace.

Three tiers are enough to start. As an example, a payroll SaaS or a managed service provider with administrator access is high risk, a project tool holding internal documents is medium, and a stock image subscription with no access or business data is low. The tier sets the assessment depth, the contract terms you insist on, how often you review and whether you need an exit plan. Re-tier when the data or access changes.

3. Due diligence at onboarding

Do it before the contract is signed and before the vendor gets data or access. The vendor selection guide covers references, financial information and insurance. The vendor security assessment guide covers the security evidence and the questionnaire.

Decide each finding before go-live: accept it, have it fixed first, write a fix and a date into the contract, or walk away. Record who accepted any remaining risk.

4. Contract controls

The contract turns due diligence findings into obligations. The key clauses are below.

5. Ongoing monitoring

Watch for changes that move the risk:

• A new independent audit report or certificate, and any exceptions in it
• New sub-processors, changed terms or a change of ownership
• Incidents, outages and missed service levels
• Accounts, tokens and integrations the vendor still holds, and data beyond what its tier assumed

Set a review cadence by tier, and review any vendor after a trigger such as an incident, an acquisition or a new integration.

6. Issue and incident management

Log every finding with an owner, a due date and any compensating control, and follow it to closure. Your incident response plan should name each high-risk vendor’s contacts, how it will tell you about an incident and what you’ll need from it, such as the data affected and relevant logs.

7. Renewal, exit and offboarding

Well before the notice deadline, decide whether to renew, renegotiate or leave, using both the risk and performance records. When any vendor relationship ends:

• Revoke the vendor’s accounts, single sign-on access, API keys, remote access and shared credentials.
• Remove its integrations and agents from your systems.
• Get your data back in a usable format.
• Get written confirmation that your data has been deleted, including backups, on the timeline the contract sets.
• Update the inventory.

Risk types and controls

Contract clauses that carry the program

Put these in the RFP so bidders price and accept them before award. The free RFP template includes several in its security and commercial sections; the cybersecurity RFP guide covers incident and exit terms.

• Security requirements. Controls the vendor keeps for the whole term, including a current independent audit report or certification covering your service.
• Audit rights. Your right to receive audit reports, ask follow-up questions and, where it matters, assess the vendor. SaaS vendors may offer independent reports instead of customer audits; decide in advance what you’ll accept.
• Incident notification within a defined time. State the time, when the clock starts, what the notice must contain and how the vendor will cooperate, with your own legal deadlines in mind.
• Sub-processor changes. Advance notice before a new sub-processor handles your data, and a right to object or leave.
• Service levels. How availability and support response are measured, the credits for a miss, and a right to terminate after repeated failures.
• Data return and deletion. The format and timeline for returning your data, and written confirmation of deletion.
• Termination assistance. Help moving to a new provider, with service continued through the transition.

Have counsel review the wording. In regulated sectors such as banking or health care, regulators may set their own vendor oversight requirements, so check with your compliance team.

Who owns what

Give the program one owner, often in procurement, security or IT risk, and share the work:

• Business owner: requests the vendor, owns the relationship and accepts remaining risk.
• Procurement: runs intake, negotiates the clauses and keeps the renewal calendar.
• IT: grants and removes access, and reviews architecture and integrations.
• Security: sets assessment requirements by tier, reviews evidence and leads the response to vendor incidents.
• Legal and privacy: contract terms, data processing agreements and the laws that apply.
• Finance: spend data that reveals unknown vendors, and financial reviews.

Keeping it proportionate for a small team

Cover every vendor lightly and the riskiest ones properly. Start with four things:

• A vendor list: a spreadsheet with the fields from step 1.
• Tiers: three, each defined in a sentence, applied to every vendor.
• A short questionnaire for low-risk vendors: a few questions on where data is stored, single sign-on, incident reporting and deletion at exit. Save the full assessment for high-risk vendors.
• A renewal calendar: every notice date, with a review booked ahead of each one.

Then add one rule: nothing new gets data or access until it has a tier.

Vendor risk management vs performance management

Risk management asks what could go wrong with a vendor and whether the controls still hold. Performance management asks whether the vendor delivers what the contract promised, such as service levels and support response. Both are part of IT vendor management and both feed the renewal decision, but they’re separate jobs with separate records.

For performance after the contract is signed, use the free vendor scorecard template, which rates a supplier you already use against its contract each quarter. For the security step in the lifecycle, read the vendor security assessment guide.

Frequently asked questions

What is vendor risk management?

It’s the ongoing work of finding, rating and controlling the risks your suppliers bring, from before you buy until the relationship ends. For technology vendors, it focuses on the data they hold, their access to your systems, how much you depend on them and their own suppliers.

What are the steps in vendor risk management?

Inventory every vendor, tier each one by risk and run due diligence before onboarding. Then write controls into the contract, monitor the vendor, manage issues and incidents, and finally renew or exit, revoking access and confirming your data is returned or deleted.

What is the difference between vendor risk management and vendor management?

Vendor management covers the whole supplier relationship, including contracts, spend, performance and renewals. Vendor risk management is the part focused on what could go wrong, such as a breach, an outage or a vendor failing, and the controls that reduce it.

What is a fourth party?

A fourth party is your vendor’s supplier, such as the hosting provider your SaaS vendor runs on or a sub-processor that receives your data. You usually have no contract with them, so you manage the risk through your vendor: a current sub-processor list, notice of changes and security terms passed down.

How do you tier vendors by risk?

Rate each vendor on the data it holds, its access to your systems, how critical its service is and how hard it would be to replace. Group the results into tiers such as high, medium and low, and let the tier set assessment depth, contract terms and how often you review.