Third-Party Risk Management Requirements: A Practical Checklist

If you sell to enterprise customers or you're pursuing a SOC 2 report, "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 a SOC 2 report 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.

How to build the inventory when nobody knows what you use

Ask a founder how many vendors the company uses and the answer is usually a dozen or two. The real number is higher, often much higher. The list that finance keeps is a list of things with invoices, and a great deal of third-party access arrives without one: free tiers, trials that never got cancelled, browser extensions with OAuth scopes, a contractor's own tooling, an AI assistant somebody connected to the shared drive on a Thursday afternoon.

Four sources will get you to a real inventory faster than asking people. Pull the OAuth grants and connected applications list from your identity provider, which shows anything holding a token against your Google or Microsoft tenant. Pull twelve months of card and expense transactions and filter for anything recurring under $200, which is where shadow tooling hides. Pull your DNS or egress logs for a week and look at the destinations nobody can explain. And export the integration list from your core systems: the CRM, the code repository, the cloud account, the support desk. Reconcile those four against the finance list and you will typically find two to four times the number of third parties anyone expected.

Record more than the vendor name. For each one you want the data categories they can reach, the access mechanism (API token, SSO, direct database, human login), the internal owner by name rather than by department, the contract renewal date, and whether the relationship is a processor or a controller in privacy terms. That last field decides which contract obligations apply and it is the field most inventories omit.

Tiering criteria that survive an argument

Tiering falls apart when it depends on judgment alone, because every owner believes their vendor is low risk. Make it mechanical. Score each vendor on four axes: sensitivity of data reachable, volume of records, depth of access to your production environment, and availability impact if the vendor disappears tomorrow. Any vendor that can reach production, can reach customer personal information, or would stop your product from functioning goes into the top tier regardless of spend.

The spend trap is worth naming. Companies routinely tier by contract value, which produces a program that scrutinizes a $90,000 data warehouse and ignores a $40 per month error-tracking tool that receives full request payloads including session tokens and customer email addresses. Price correlates with commercial risk, not with security risk. We have seen deep reviews on office software while the actual crown-jewel exposure sat in a logging integration nobody had tiered at all.

Write your tier definitions into the policy with the criteria attached, and put the number of vendors in each tier on a slide for leadership. If your top tier contains forty vendors, either your criteria are too loose or you have a genuine architecture problem, and both are worth knowing.

Reading a SOC 2 report properly

Collecting a vendor's SOC 2 Type II is the easy part. Reading it is where the actual risk reduction happens, and most teams read the first page and file it. There are six things worth checking, and each of them has produced a real finding in engagements we have run.

Check the report period against today's date. A report covering January to December of the year before last tells you nothing about the current control environment, and if the gap is more than three months you should be asking for a bridge letter from the vendor's management covering the interval.

Check the scope section for which systems are actually covered. Vendors with several products routinely certify one of them. If the report covers the enterprise platform and you use the self-serve product on different infrastructure, the report does not apply to you.

Check the Trust Services Criteria included. Security is the baseline. Availability, Confidentiality, Processing Integrity and Privacy are optional, and a vendor you depend on for uptime who has not included Availability has not been tested on the thing you care about.

Read the auditor's opinion for qualifications, then read the testing exceptions in section four even when the opinion is clean. Exceptions are common and not automatically alarming, but an exception in access provisioning or change management is a different signal from one in a physical security control at a data center you never enter.

Read the complementary user entity controls. These are the things the vendor assumes you are doing, and their report is only valid if you are. Typically they include enforcing MFA on your own administrator accounts, reviewing your user list, and configuring the product's own security settings. If nobody on your side has ever read that list, you have inherited assurance you are not entitled to.

Finally, check whether subservice organizations are carved out or included. A carve-out means the vendor's own cloud provider was excluded from testing, which is usually fine, but it also means the report says less than it appears to.

Subprocessors, and the fourth parties you never signed with

Your vendor's vendors process your data too. The practical control here is not to assess them all, which is impossible, but to require notice. Contract terms should oblige the vendor to maintain a published subprocessor list, to notify you before adding one, and to give you a defined objection window. Then somebody on your side actually has to watch the notifications, which is the step that never gets assigned.

Pay particular attention to changes in AI subprocessing. A support platform or a note-taking tool that quietly adds a model provider to its subprocessor list has changed where your customer data goes, and increasingly your own enterprise customers will ask you about it directly. If you are answering buyer questionnaires already, expect this question to appear in the next revision of whatever standard set they use.

Concentration and continuity

Most vendor programs assess confidentiality and ignore availability, which is backwards for a lot of businesses. Map how many of your top-tier vendors sit on the same cloud provider, in the same region. Map which single vendor, if it went dark for a week, would stop you invoicing, stop you deploying, or stop your customers logging in. That is concentration risk, and enterprise buyers in financial services will ask about it explicitly.

For each of those, the requirement is an exit position, not just a backup plan: can you get your data out in a usable format, do you know the export mechanism, has anyone tested it, and roughly how long would a migration take. A one-page answer per critical vendor is enough. Having none is what turns a vendor's acquisition or price increase into a crisis.

What auditors actually test

During a SOC 2 examination the vendor management control usually gets tested three ways. The auditor takes the population of vendors onboarded during the period and samples several, then asks for the review that was performed before go-live and the date it was performed. If the review is dated after the contract start, that is an exception, and it is the single most common vendor management finding we see. Companies do the assessment, but they do it in month three because the tool went live in month one.

Second, the auditor samples from your top-tier list and asks for the current-period evidence: the SOC 2 report on file, the date it was reviewed, and who reviewed it. A report sitting in a folder with no review record does not demonstrate the control operated. Add a short review memo, four or five lines, noting the period, the exceptions, the user entity controls, and the conclusion. That memo is the evidence, not the report.

Third, the auditor tests terminations. They will take a vendor whose contract ended during the period and ask when access was revoked. Stale credentials at a departed vendor are tested under logical access as well as vendor management, so one lapse produces two findings.

Cost drivers, and where teams overspend

The expensive part of third-party risk is never the questionnaire. It is the follow-up: chasing vendors who ignore requests, escalating through the internal owner, interpreting a report that raises a new question, and re-running the whole thing next year. Budget by top-tier vendor count and assume real elapsed effort per vendor per year rather than a one-time project cost.

Two overspends recur. The first is buying a dedicated third-party risk platform at a stage where the company has eleven meaningful vendors, at which point a spreadsheet with a review date column and a calendar reminder does the same job with less administration. The second is commissioning custom questionnaires per vendor. Use a standard set, accept the vendor's completed CAIQ or SIG if they have one, and spend the saved time reading evidence instead of collecting more claims. If you want a free place to keep the register and the evidence without adding a subscription, the traztech Workspace is available at no cost and holds the inventory, the tier, the review dates and the documents in one place.

When something goes wrong at a vendor

The first hour of a vendor breach is mostly information triage, and the questions are predictable enough to prepare. What data of ours was in that system, and for what period? Which of our customers' records are implicated? Were credentials or tokens exposed, and if so, which of our systems accepted them? Do we have a contractual notification obligation to our own customers, and on what clock does it start?

The answers come from the inventory field you were told to record earlier: data categories and access mechanism. If your inventory says only "CRM tool, marketing, $600 per month", you will spend the first day reconstructing what should already have been written down. Rotate every credential the vendor held, including any long-lived API tokens, and do it before you finish the assessment rather than after, because token revocation is cheap and waiting is not. If the incident touches personal information of Canadians, the reporting analysis under PIPEDA and, where Quebec residents are involved, Law 25, runs in parallel and on a tighter clock than most teams expect. Working out your escalation path in advance is worth more than any questionnaire, and it is one of the things we set up under an ongoing retainer.

When you should not build this yet

There is a version of third-party risk management that is pure theatre, and buying it early is a genuine waste of money.

If you are a ten-person company with a dozen vendors and no audit in front of you, do not buy a platform and do not hire anyone. Write the inventory in a spreadsheet, tier it in an afternoon, collect SOC 2 reports for the three vendors that hold customer data, and set a calendar reminder for twelve months. That is a defensible program at your stage and it costs a day.

If your driver is a single enterprise deal, find out what that buyer actually requires before generalizing. Some procurement teams want to see your register and your tier definitions. Some want a named owner and nothing else. Building a nine-part program to answer a question nobody asked delays the deal you were trying to unblock.

If you already have a functioning program and the gap is only that nobody is running it, the answer is ownership, not more process. Adding a fifth review stage to a program that fails at follow-through makes the failure larger. Assign one person, give them the calendar, and measure whether reviews happened on time for two quarters before adding anything.

And if a consultant proposes to assess all ninety of your vendors in a fixed-price engagement, ask what happens to the output in month thirteen. A snapshot assessment of every vendor is easy to sell and rarely worth what it costs. The recurring review of the ten that matter is the part with value, and it is the part that gets quietly dropped. We would rather scope you the smaller version that survives, which is how our compliance work is structured.