Vendor Risk Management Process: 6 Steps to a Program

The vendor risk management (VRM) process is the repeatable cycle of inventorying your third-party vendors, assessing the risk each one introduces (security, financial, compliance, operational), tiering them by criticality, remediating the gaps you find, and monitoring them on a fixed cadence. It matters because your SOC 2 or ISO 27001 auditor holds you accountable for your vendors' security, not just your own.

The vendor risk management process in 6 steps

Third party risk management is a loop, not a one-time project. A vendor you cleared last year can lose a certification, get acquired, or start handling data it never touched before. These six steps are the vendor risk management framework most 5 to 200 person companies run, and they map cleanly onto what a SOC 2 or ISO 27001 auditor expects to sample.

1. Build a vendor inventory

You cannot assess what you have not listed. Start by pulling every recurring charge from accounting, every SSO-connected app from your identity provider, and every integration from engineering. The output is a single register: vendor name, owner inside your company, what the vendor does, and, critically, what data or systems it touches. Most teams are surprised by the count. A 40-person company routinely runs 60 to 120 SaaS vendors once shadow IT is included. This inventory is the spine of the whole process, and it is the first thing an auditor asks for.

2. Tier vendors by risk and criticality

Not every vendor deserves the same scrutiny. A payroll processor holding SSNs and a design tool holding nothing sensitive are different risks, and treating them identically wastes effort on the second while under-reviewing the first. Tier each vendor by two questions: what data does it access, and what breaks if it goes down? The tier sets your review depth and reassessment cadence for everything that follows.

3. Assess each vendor

For Tier 1 and Tier 2 vendors, gather evidence that the vendor manages its own security. Three artifacts do most of the work: a completed security questionnaire, a current SOC 2 Type II report (or ISO 27001 certificate), and a certificate of insurance. Read the SOC 2 report rather than filing it, and check three things: the report period is recent, the scope covers the service you actually buy, and the exceptions section holds no findings that touch your data. Where the vendor cannot provide a SOC 2 report, a completed questionnaire (SIG Lite or CAIQ are common) plus their subprocessor list becomes your evidence instead.

4. Remediate and document

An assessment that surfaces a gap and stops there is worthless. When a vendor lacks MFA on admin accounts, has an expired certification, or names a subprocessor in a jurisdiction you cannot accept, log the finding, assign an owner, and set a due date. Some gaps you push the vendor to fix; some you mitigate on your side (scoping down the data you send); some you formally accept with a named approver. The point an auditor checks is that the finding went somewhere, not that every vendor was perfect.

5. Contract controls

Assessment tells you the vendor's posture today; the contract binds them going forward. For any vendor touching personal data, a signed Data Processing Agreement (DPA) is the baseline, and GDPR Article 28 makes it mandatory. Push for a few more clauses on Tier 1 vendors: a breach notification window (48 to 72 hours is standard), a right-to-audit or a commitment to maintain SOC 2, a subprocessor change-notice term, and clear data deletion obligations at termination. A vendor that refuses every security clause is itself a risk signal.

6. Continuous monitoring and annual reassessment

Vendor risk decays. Certifications expire, breaches get disclosed, and the tool you approved for analytics quietly ships a feature that now reads customer records. Continuous monitoring means watching for those changes between formal reviews: subscribe to vendor status and security pages, watch for breach news on your Tier 1 list, and diff each renewed SOC 2 report against last year's. Then reassess on the cadence the tier set, pulling a fresh SOC 2 report and confirming the data-access assumptions still hold.

Running this loop across dozens of vendors in a spreadsheet is where most programs quietly break: reassessment dates slip, expired reports go unnoticed, and findings lose their owners. Purpose-built vendor risk management software tracks each vendor's tier, evidence, findings, and review dates in one place and puts reassessments on a calendar so nothing expires silently.

What is the vendor risk management process?

The vendor risk management process is the ongoing cycle of identifying every third-party vendor your company relies on, assessing the security, compliance, financial, and operational risk each one introduces, tiering them by how critical they are, remediating the gaps, and monitoring them over time. It exists because your vendors handle your data, and their failures become your incidents and your audit findings.

What are the 5 phases of vendor risk management?

The five phases of vendor risk management are: (1) identification, building a complete vendor inventory; (2) assessment, evaluating each vendor's security and compliance posture; (3) mitigation, remediating gaps and adding contract controls; (4) monitoring, watching for changes between reviews; and (5) reporting, producing the records an auditor or your board samples. Some frameworks add onboarding and offboarding as distinct phases, but these five cover the core lifecycle. The six-step process above simply splits assessment and contracting into separate steps for clarity.

How do you assess a vendor's security?

You assess a vendor's security by collecting and reviewing evidence rather than taking their word. The three standard artifacts are a completed security questionnaire, a current SOC 2 Type II report or ISO 27001 certificate, and a certificate of insurance. For higher-risk vendors, add a penetration test summary and their subprocessor list. Reading the SOC 2 report is the substance of a vendor risk assessment: confirm the report period is current (typically covering the last 12 months), the scope matches the product you buy, and the exceptions do not touch your data. Beyond documents, verify the vendor enforces MFA, encrypts data at rest and in transit, and has a documented incident response process. It also helps to track each vendor's certificate of insurance so coverage gaps and lapsed policies surface before a claim, not after.

What is a vendor risk assessment?

A vendor risk assessment is the evaluation of a single vendor to determine how much risk it introduces to your organization and whether that risk is acceptable. It combines the vendor's tier (based on data access and criticality) with evidence of their security controls to produce a decision: approve, approve with conditions, or reject. The assessment is one step inside the broader vendor risk management process, and it is closely related to your internal compliance risk assessment: vendor concentration and unreviewed processors are risks that belong on both registers. A good vendor risk assessment is repeatable, meaning two people assessing the same vendor with the same evidence reach the same conclusion.

Why does SOC 2 require vendor risk management?

SOC 2 requires vendor risk management because you cannot outsource accountability. Control CC9.2 in the Trust Services Criteria expects you to assess and manage the risks your vendors and business partners introduce, since data you hand to a subprocessor is still your responsibility to protect. If your payroll provider or cloud host suffers a breach, your customers experience it as your breach. Auditors sample your vendor list, ask for the SOC 2 reports of your critical vendors, and check that you reviewed them rather than filing them. ISO 27001 mirrors this through its supplier security controls (A.5.19 to A.5.22), which cover supplier relationships, addressing security in agreements, managing the ICT supply chain, and monitoring supplier service delivery. A clean vendor register with dated reviews is one of the faster wins in a SOC 2 compliance software program, because it turns a control the auditor always checks into evidence you already have.

Vendor risk management best practices

• Assess before you sign, not after. The strongest leverage to demand security controls is during procurement, before the contract is signed and the data is flowing.
• Right-size by tier. A full assessment on a Tier 3 stock-photo vendor is wasted effort that steals attention from the payroll provider that actually matters.
• Read the reports, do not just collect them. A filed SOC 2 report you never opened proves nothing; the exceptions section is where the risk lives.
• Put reassessments on a calendar. The most common failure is a program that assesses every vendor once and never again, so certifications expire unnoticed.
• Connect vendors to your control set. A vendor register that floats beside your compliance program, rather than feeding it, is the parallel imaginary program auditors see through.

The usual boundary applies: a vendor risk management process is required input for SOC 2 and ISO 27001, but it does not by itself certify anything or guarantee an audit outcome. What it does is make a control your auditor always tests into something you can show on demand, and keep a vendor's quiet failure from becoming your loud incident.