Vendor management is the operational discipline of running each vendor relationship through its full lifecycle: keeping an inventory, selecting and contracting vendors, onboarding them, overseeing performance against service levels, handling renewals, and offboarding them cleanly when the relationship ends.
It is the day-to-day work that keeps outside providers organized, owned, and accountable. Procurement, legal, finance, IT, and security all touch it. The goal is simple: every vendor your company relies on has a named owner, a current contract, known access, and a clear exit path.
In simple terms, vendor management answers:
- Which vendors do we use, who owns each relationship, and what do they touch?
- Are they delivering what the contract promises?
- When we renew or leave, do we follow a repeatable process and keep the records?
This page defines the operational discipline. For the risk side, meaning how you judge, accept, and monitor the risk a third party creates, see What Is Third-Party Risk Management?. For the SOC 2 operating playbook on vendor risk reviews and evidence, see Vendor Management for SOC 2: Risk Reviews and Evidence.
Why Vendor Management Matters
Modern companies run on vendors: cloud hosting, identity, payments, support desks, analytics, payroll, and contractors. Each one adds cost, dependency, and often access to systems or data.
Vendor management matters because:
- Vendors nobody owns tend to keep access, auto-renew, and drift out of view.
- Contracts set the terms you can enforce later, including service levels, security duties, data return, and notice periods.
- Onboarding is the moment to scope access and data sharing before habits form.
- Performance problems surface earlier when someone reviews service levels on a schedule.
- Offboarding is where access and data most often get left behind.
- Auditors and customers expect to see vendor relationships governed with dates and owners, not handled through scattered email.
Good vendor management also makes third-party risk management workable. Risk reviews depend on an accurate inventory, current contracts, and owners who respond.
The Vendor Management Lifecycle
Most programs follow the same stages, scaled to how important each vendor is.
1. Inventory
Keep one authoritative vendor list. Common fields include vendor name, service provided, business owner, contract dates, cost, data shared, system access, criticality, and status (active, renewing, offboarding, or ended). An inventory with no owner column is a warning sign.
2. Selection
Define the need, compare options, and record why you chose the vendor. For vendors that will handle sensitive data or support critical services, selection is also when security and risk review should start, before anyone signs.
3. Contracting
Put expectations in writing. Typical terms cover scope of services, service levels, support and escalation paths, confidentiality, security and breach notification duties, subprocessors, data ownership, data return or deletion at exit, renewal terms, and termination rights. Legal owns the wording, but the business owner should know what was agreed.
4. Onboarding
Set the vendor up on purpose. Grant only the access the vendor needs, record which data flows to them, add the vendor to the inventory, and assign the internal owner. Onboarding tickets with approvals are easier to prove later than chat messages.
5. Performance and SLA oversight
Review delivery against the contract on a cadence that fits the vendor. Look at uptime or response commitments, open issues, incidents, support quality, and cost. Record the review even when everything is fine, and track issues to resolution.
6. Renewal
Renewal is a natural checkpoint. Before renewing, confirm the vendor still meets the need, the owner is current, access is still right-sized, and any risk review due at renewal is complete. Avoid silent auto-renewals for important vendors.
7. Offboarding
When a relationship ends, revoke vendor accounts and integrations, rotate shared credentials or API keys, confirm data return or deletion as the contract requires, settle final obligations, and mark the inventory record as ended. Keep the confirmation.
Vendor Management vs Related Terms
| Term | Primary job | How it relates to vendor management |
|---|---|---|
| Vendor management | Run vendor relationships through their lifecycle | The operational backbone: inventory, contracts, onboarding, oversight, renewal, and exit |
| Third-party risk management (TPRM) | Identify, assess, monitor, and treat risk from external parties | Uses vendor management records to make and revisit risk decisions |
| Procurement | Buy goods and services on commercial terms | Often runs selection and purchasing; vendor management continues after the purchase |
| Contract management | Draft, approve, store, and track agreements | One stage of the lifecycle, focused on terms and dates |
| Due diligence | Point-in-time review of a vendor before or during the relationship | An input to TPRM, usually triggered by vendor management milestones |
The short version: vendor management keeps the relationship running and documented. TPRM decides whether the risk is acceptable and how to watch it. Most companies need both, and both work from the same inventory.
Examples of Vendor Management Activities and Evidence
| Activity | Example evidence |
|---|---|
| Inventory upkeep | Dated vendor list export with owners, criticality, and status |
| Selection | Request ticket, comparison notes, approval record |
| Contracting | Signed agreement with security and data terms, renewal date |
| Onboarding | Access request and approval, data flow note, inventory entry |
| Performance review | Service level report, review notes, issue tickets |
| Renewal | Renewal decision record, confirmed owner, refreshed review where required |
| Offboarding | Access removal ticket, credential rotation, data return or deletion confirmation |
Good vs poor examples:
- Good: a support desk vendor onboarded through a ticket that names the owner, limits agent access to one queue, and logs the data shared.
- Poor: a team signs up with a corporate card, invites the vendor into production chat, and nobody records it.
- Good: a quarterly service review for the hosting provider, with notes and two tracked issues.
- Poor: the first look at the vendor's performance happens during a customer escalation.
- Good: an ended analytics contract with revoked API keys and a deletion confirmation on file.
- Poor: the contract ends, but the vendor's integration still holds a live token months later.
For broader evidence habits, see What Is SOC 2 Evidence? and audit evidence.
Framework Notes
SOC 2
The AICPA 2017 Trust Services Criteria with revised points of focus (2022) address vendors in CC9.2: the entity assesses and manages risks associated with vendors and business partners. The points of focus under CC9.2 read like a lifecycle. They include establishing requirements for vendor engagements (such as scope of services, roles, compliance requirements, and service levels), assigning responsibility for managing vendors, assessing vendor performance, addressing issues found during vendor assessments, and implementing procedures for terminating vendor relationships. Points of focus are illustrative guidance, not a mandatory checklist.
SOC 2 does not prescribe a vendor tool, a review frequency, or a contract template. You define the process, and your auditor tests whether it operated. Vendor accounts in your systems also fall under the access criteria in CC6. For Type 2 reports, expect samples from across the audit period, such as vendors onboarded or relationships ended during the window. See SOC 2 Type 1 vs Type 2 and What Are the Trust Services Criteria?.
NIST Cybersecurity Framework 2.0
The NIST Cybersecurity Framework (CSF) 2.0 includes a Cybersecurity Supply Chain Risk Management category (GV.SC). Its outcomes follow the lifecycle: suppliers are known and prioritized by criticality (GV.SC-04), security requirements are built into contracts (GV.SC-05), due diligence happens before a relationship starts (GV.SC-06), and plans cover activities after a relationship ends (GV.SC-10). CSF is voluntary guidance, not a SOC 2 requirement, but it is a useful structure.
ISO 27001
ISO 27001 programs address supplier relationships in Annex A of ISO/IEC 27001:2022, including controls for information security in supplier relationships, supplier agreements, and monitoring and change management of supplier services. Teams that run both programs often reuse one vendor process through control mapping.
Common Failures
- Several vendor lists that disagree, or none at all
- Vendors with no named internal owner
- Contracts with no security, data return, or service level terms
- Vendor access granted at onboarding and never reviewed
- Auto-renewals that skip any check
- Performance problems handled in email with no record
- Offboarding that ends the invoice but not the access
- Treating vendor management and risk review as the same task, so neither is done well
Many of these become exceptions or audit findings when they are found late.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as Jira, Okta, and Google Workspace.
For vendor management, that can mean dated history for vendor onboarding and offboarding tickets, approvals, and vendor account changes, so the records are ready when an auditor samples them. Your GRC platform or vendor tool remains the system of record for vendor reviews and contracts. AuditFlo does not select or assess vendors, does not negotiate contracts, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
Vendor management is the operational discipline of running every vendor relationship from inventory and selection through contracting, onboarding, performance oversight, renewal, and offboarding. It sits beside third-party risk management: vendor management keeps relationships owned and documented, while TPRM judges the risk. For audits, the strongest proof is a current inventory with owners, signed terms, onboarding and offboarding tickets, and dated performance reviews.