If you sell to enterprise customers or you're pursuing SOC 2 certification, "third-party risk management" stops being a nice-to-have and becomes a line item an auditor or a procurement team will ask you to prove. The problem is that most companies treat it as a single task ("send vendors a questionnaire") when it's actually a program with several distinct, recurring requirements. Below is a practical checklist of what's actually expected, with a short explanation of why each item matters.
1. A vendor inventory
You cannot manage risk from vendors you haven't catalogued. This means a living list of every third party that touches your systems, your data, or your customers' data: cloud infrastructure, SaaS tools, payment processors, contractors with system access, even the marketing platform that stores lead emails. For each vendor, record what data they can access, what system they connect to, and who owns the relationship internally. Auditors will ask for this list by name during a SOC 2 examination.
2. Risk tiering
Not every vendor deserves the same scrutiny. A payroll processor handling employee banking details is a different risk category than a scheduling tool with no data access. Tier vendors (commonly high, medium, low) based on the sensitivity of data they touch and the depth of system integration. Tiering determines how much due diligence you do at onboarding and how often you re-review the vendor afterward. Skipping this step is the most common reason TPRM programs collapse under their own weight, teams try to apply the same deep review to every vendor and give up.
3. Security questionnaires at onboarding
Before a new vendor goes live, especially anything in your high or medium tier, you need a documented review of their security posture. This doesn't have to be a custom 200-question survey. A standardized questionnaire covering access controls, encryption, incident response, and subprocessor use is enough for most vendors. The point is that the review happened and is on file, not that it's exhaustive.
4. Evidence review, not just self-attestation
A vendor telling you they're secure isn't evidence. For any vendor in your critical path, ask for something independently verifiable: a SOC 2 Type II report, an ISO 27001 certificate, or a recent penetration test summary. Read the report, not just the cover page, and look at the auditor's opinion and any noted exceptions. If a vendor can't produce anything, that's itself a data point for your risk tiering.
5. Contractual security terms
Verbal assurances don't hold up. Contracts with vendors that touch sensitive data should include a data processing addendum, defined data handling obligations, and a breach notification clause with a specific timeframe (30 days is common, but tighter is better for high-risk vendors). If your legal team isn't already looping security into vendor contract review, that's a gap worth closing before it shows up in an audit finding.
6. Ongoing monitoring, not a one-time check
This is the requirement most programs miss entirely. Vendor risk isn't static, a supplier that passed review two years ago may have changed ownership, suffered a breach, or quietly dropped a security certification. Ongoing monitoring means re-reviewing high-tier vendors on a set cadence (annually at minimum), tracking vendor security incidents that get publicly disclosed, and re-collecting SOC 2 reports as they're renewed. This is the piece our third-party risk management service is built around: assessing vendors once is easy, monitoring them continuously is where most internal teams run out of bandwidth.
7. Access and offboarding controls
When a vendor relationship ends, or when a vendor's scope of access shrinks, their system credentials need to be revoked on a defined timeline. Auditors specifically test for stale vendor access as part of SOC 2 logical access reviews. Keep an offboarding checklist that ties back to your vendor inventory so nothing gets missed when a contract lapses.
8. Incident notification requirements
Your program needs a documented process for what happens when a vendor tells you they've had a breach, or when you find out through other means. This includes who gets notified internally, how you assess whether your data was affected, and how you communicate to your own customers if required. Waiting until an incident happens to figure this out costs time you won't have.
9. Reporting up
Leadership and, where applicable, the board need visibility into vendor risk, not line-item detail on every SaaS tool, but a summary of high-risk vendors, outstanding review gaps, and any unresolved findings. This is also what auditors expect to see referenced in governance documentation during a SOC 2 review.
Why this matters more than it used to
Enterprise buyers increasingly push their own security requirements down through their supply chain, and SOC 2 auditors test vendor management as a standalone control area, not a footnote. A vendor inventory and a folder of unread questionnaires won't satisfy either one. What holds up is a program with clear ownership, defined tiers, real evidence review, and monitoring that continues after onboarding. If you're building this alongside a broader SOC 2 certification effort, it fits naturally into our wider compliance work, since the same control evidence tends to serve both purposes.
If you're not sure whether your current vendor review process would hold up under an auditor's questions, or you're starting a TPRM program from scratch, get in touch and we'll walk through what's actually required for your situation.