Third-party risk management for SaaS vendors: a practical checklist
Many companies now run more than a hundred SaaS applications, and every one of them is a third party: a vendor with some access to your data, your systems, or your customers. Most of those tools arrived one team at a time, often on a credit card, and very few went through anything resembling a security review.
Third-party risk management (TPRM) is the discipline of knowing who those vendors are, how much risk each one carries, and whether they're still meeting your expectations. Big banks have whole teams for it. This article is for everyone else: a practical process you can run with the people you already have.
Why TPRM stopped being optional
Pressure comes from several directions at once. Your own customers send you security questionnaires and expect you to hold your vendors to the same standard. Public companies must describe how they identify and manage cybersecurity risks from third-party service providers under the SEC's 2023 disclosure rules. Banks follow the federal banking agencies' Interagency Guidance on Third-Party Relationships, which walks through the whole vendor lifecycle. New York's financial regulator requires a third-party service provider security policy (NYDFS Part 500), the FTC Safeguards Rule requires many non-bank financial companies to oversee their service providers, and HIPAA requires a business associate agreement before a vendor touches health data.
Even if none of those apply to you directly, the NIST Cybersecurity Framework 2.0 made cybersecurity supply chain risk management part of its new Govern function. It's quickly becoming the baseline auditors and customers expect.
A lifecycle you can actually run
1. One front door for new vendors. Every new tool, including free trials and AI tools, starts with a short intake: what it's for, who owns it, what data it touches, and whether you already pay for something similar. This single step catches most shadow IT and duplicate spend.
2. Tier by risk. A vendor with admin access to production or your customer data is high risk. A design plugin with no data access is low risk. Spend your review effort on the top tier and keep the bottom tier fast, or teams will route around the process.
3. Due diligence that matches the tier. For high-risk vendors: a current SOC 2 Type II report, a security questionnaire, and a privacy review. For low-risk ones, a few intake questions may be enough. Read the SOC 2 report properly (we wrote a separate guide on that).
4. Put it in the contract. Security obligations, breach notification timeframes, your right to audit, data return and deletion at the end, and, for SaaS, the renewal terms and any cap on price increases.
5. Ongoing monitoring. Collect a new SOC 2 report every year, watch for incidents and ownership changes, and review high-risk vendors at least annually. A vendor that was safe at signing isn't guaranteed to stay that way.
6. Offboarding. Remove accounts, API keys and integrations, and get written confirmation that your data was returned or destroyed. Forgotten integrations with old vendors are a common way in for attackers.
Get the checklist
We've turned this process into a free, printable third-party risk checklist with 35 checks across the whole lifecycle, tagged where SOC 2, NIST, HIPAA, state privacy laws, state AI laws or financial-sector rules come in.
How Granur helps
Granur gives every vendor and AI tool the same intake and a risk-based evaluation with compliance screening for frameworks like SOC 2, NIST CSF, HIPAA and CCPA/CPRA. Vendors upload their own SOC 2 reports and certificates through a secure link, Granur's AI reviews SOC 2 reports for scope and exceptions, and contract renewal dates and obligations are pulled out automatically. Every decision leaves an audit trail you can hand to a customer or auditor.