Third-Party Risk Management Requirements: A Practical Checklist

Third-party risk management (TPRM) requires a documented process to identify, assess, and monitor the security risk every vendor introduces to your business, covering vendor inventory, risk tiering, due diligence, contractual controls, and ongoing monitoring. SOC 2 auditors and enterprise security reviewers expect to see all five in place before they sign off, not just a spreadsheet of vendor names.

For a Canadian B2B SaaS company trying to close a US enterprise deal, TPRM is often the checklist item that surfaces last and blocks the deal longest. Below is the practical version of what auditors and enterprise security teams actually ask for, organized so you can work through it in order.

What SOC 2 and Enterprise Buyers Actually Expect From Your TPRM Program

SOC 2's Common Criteria (CC9) requires you to identify vendors that could affect your service commitments and manage the risk they introduce. Enterprise security questionnaires (SIG, CAIQ, or a custom form from the buyer's InfoSec team) ask the same question in different words: how do you know your vendors won't be the reason your customer's data leaks. Neither wants a narrative. Both want evidence: a vendor list, a risk rating methodology, signed agreements, and a record of periodic review. If any one of those pieces is missing, expect a finding or a stalled deal.

Vendor Inventory and Risk Tiering Checklist

• Complete vendor inventory. Every subprocessor and third party that touches customer data, code, or infrastructure, not just the obvious ones like your cloud host. Payroll providers, analytics tools, and support chat widgets belong on the list too.
• Data classification per vendor. Record what data each vendor can access: none, internal only, customer PII, or regulated data. This drives everything downstream.
• Risk tier assignment. Tier vendors (high, medium, low) based on data access and business criticality. A vendor holding customer financial data gets far more scrutiny than a scheduling tool with no data access.
• Owner assigned per vendor. Someone internal is accountable for each vendor relationship and its review cadence. Auditors will ask who owns this.

Due Diligence Requirements Before You Sign a Vendor

• Request the vendor's SOC 2 report or equivalent. For high-tier vendors, a current SOC 2 Type II report (or ISO 27001 certificate) is the baseline ask. No report means you do deeper diligence yourself.
• Review the report's exceptions and complementary user entity controls (CUECs). A clean-looking report can still have exceptions that matter to your risk exposure, and CUECs describe controls you're expected to run on your end.
• Check subprocessor lists. Your vendor's own vendors are your fourth parties. If they don't disclose subprocessors, that's itself a finding worth noting.
• Confirm data residency and breach notification terms. Particularly important for Canadian companies subject to PIPEDA and, if you have Quebec customers, Law 25, which has its own timelines for reporting incidents involving personal information.
• Security questionnaire for lower-assurance vendors. When a vendor can't produce a report, a short standardized questionnaire covering encryption, access control, and incident history fills the gap and gives you a documented basis for the decision.

Contractual and Ongoing Monitoring Requirements

• Data processing agreement (DPA) in place. Required for any vendor touching personal data, and a hard requirement under PIPEDA and Law 25 for cross-border data flows.
• Breach notification clause with a defined timeline. Enterprise buyers and auditors both check for this specifically. Vague language ("promptly notify") is weaker than a stated number of hours or days.
• Right-to-audit clause for high-tier vendors. You don't need to exercise it often, but having it in the contract signals a mature program.
• Annual reassessment cadence. High-tier vendors get reviewed at least yearly, or whenever their SOC 2 report renews. Medium and low tiers can go on a lighter cycle, but the cadence itself needs to be documented, not ad hoc.
• Offboarding process. When you drop a vendor, you need proof that access was revoked and data was deleted or returned. Auditors ask for evidence of this more often than founders expect.
• Continuous monitoring for critical vendors. For vendors holding regulated or high-value data, periodic automated checks (certificate expiry, breach disclosures, security ratings) catch problems between annual reviews.

The Canadian Context: PIPEDA, Law 25, and Cross-Border Vendors

Most TPRM templates are written for US frameworks and skip the parts that matter most for a Canadian company. PIPEDA makes you accountable for personal information even after you hand it to a third party, which means your vendor contracts need to reflect that accountability, not just describe the vendor's own obligations. If your customer base includes Quebec, Law 25 adds stricter consent and cross-border transfer requirements that a generic US-style DPA won't cover. traztech's third-party risk management service is built around this Canadian layer specifically: vendor tiering and questionnaires that satisfy SOC 2 auditors while also holding up against PIPEDA and Law 25 obligations, which matters whether you're based in Toronto, Waterloo, Ottawa, Vancouver, Calgary, or Montreal and selling into the US.

Common TPRM Gaps That Trip Up Growing Companies

• No inventory, only memory. If the vendor list lives in one person's head, it fails the first evidence request.
• Collecting SOC 2 reports without reading them. A folder of PDFs isn't diligence if no one reviewed the exceptions or CUECs inside them.
• DPAs signed at kickoff, never revisited. Vendor terms change; your DPA library should be checked against current contracts, not the version signed two renewals ago.
• Treating every vendor the same. Applying full due diligence to a low-risk tool wastes time, while treating a high-risk vendor like a low-risk one is the gap auditors flag hardest.
• No offboarding evidence. Access revocation without a paper trail looks, to an auditor, indistinguishable from access that was never revoked.

A working TPRM program does not need to be complicated. It needs an inventory, a tiering method, a due diligence step tied to that tiering, contract language that matches your regulatory obligations, and a review cadence you can actually keep to. That combination is what gets a SOC 2 auditor to check the box and what gets an enterprise security team to stop asking follow-up questions.

traztech builds TPRM programs for Canadian SaaS companies that need to pass US enterprise security reviews without over-engineering the process, part of a broader compliance practice built for companies moving up-market. If your vendor risk process is currently a spreadsheet nobody trusts, contact traztech to scope what a defensible TPRM program looks like for your stage and industry.

How to Actually Read a Vendor's SOC 2 Report

Collecting reports is the easy half. Reading one properly takes about forty minutes and there are six things to look at, in this order.

The opinion paragraph. Unqualified means the auditor found the controls suitably designed and operating effectively. Qualified means they did not, in some specific respect that the paragraph names. A qualified opinion is not automatically a reason to reject a vendor, but it is a reason to read the exception and decide whether it touches the service you are buying. Reviewers who skip to the control matrix and never read the opinion miss the one sentence that matters most.

The period covered and the gap to today. A Type II covers a window, and that window ends on a date. If the report ended nine months ago, you have no assurance about the last nine months. Ask for a bridge letter, which is a signed statement from the vendor covering the gap between the report period end and the present, and confirming no material changes to the control environment. Vendors with mature programs produce one on request within a day. A vendor that has never heard of a bridge letter is telling you something.

The scope: which systems and which trust services criteria. Security is always in scope. Availability, confidentiality, processing integrity, and privacy are optional, and vendors choose. If you are relying on a vendor for uptime and their report covers security only, the report does not address the thing you care about. Check the system boundary too, because a vendor with five products frequently scopes the report to one of them, and it may not be the one you bought.

Exceptions in the testing section. Every deviation the auditor found is listed with management's response. Read them against your own tiering: an exception in the access review control for a vendor holding your customer PII is a different matter to a late policy review at a vendor with no data access.

Complementary user entity controls. This is the list of things the vendor assumes you are doing. Enforcing multi-factor authentication on your own admin accounts, reviewing your own user list, configuring the integration correctly. The vendor's opinion is conditional on these. Map each one to a control you actually operate, because when your own auditor asks how you rely on a vendor's report, that mapping is the answer, and almost nobody has it ready.

Subservice organizations and the carve-out method. Most reports use the carve-out method, meaning the vendor's own critical suppliers are excluded from the scope entirely and their controls were not tested. If your vendor carves out its cloud host and its data pipeline provider, the report you are holding covers less of the stack than it appears to. The inclusive method is rarer and covers more. Knowing which one you are looking at tells you where your fourth-party exposure actually sits.

Tiering Thresholds That Hold Up Under Questioning

Tiering fails when the criteria are adjectives. "Critical" and "important" are not testable, and an auditor who asks why one vendor is high and another is medium will get an answer that sounds improvised because it was. Write the thresholds as rules and apply them mechanically.

A workable set for a Canadian B2B SaaS company at Series A or B looks like this. High tier: the vendor stores, processes, or can access customer personal information or production systems, or an outage of the vendor takes your product down. That is your cloud provider, your database host, your authentication provider, your error tracking tool if it captures request bodies, your support platform if agents can see customer records. Medium tier: the vendor holds internal company or employee data, or has access to source code, but cannot reach customer data or production. Payroll, your HR system, your code host in some configurations. Low tier: no access to anything sensitive and no availability impact. Design tools, the office coffee subscription, most marketing software.

Two rules make the tiering survive contact with reality. First, the tier is a property of access, not of spend. Founders instinctively tier by invoice size and get caught out by the free tool with an OAuth token into production. Second, the tier gets reassessed when the relationship changes, not only on the annual cycle. A low-tier vendor that you later grant an API key becomes a high-tier vendor that day, and if the only review point is annual, you will carry an unassessed high-risk vendor for up to eleven months.

AI vendors deserve a specific note because they are the current source of untracked high-tier relationships. An engineer wiring a model API into a support workflow has created a subprocessor that receives customer data, and it very often never reaches the inventory. Ask the same questions you would ask anyone: what data leaves your environment, is it retained, is it used for training, where is it processed, and what does the contract say about all three.

What Auditors Sample Under CC9, and Where Programs Break

The evidence request is predictable. The auditor asks for the vendor inventory, picks a sample across tiers, and for each one wants the risk assessment on file, the diligence artifacts, the executed agreement including the data processing terms, and the most recent review with a date and a reviewer name. Then they ask for the population of vendors onboarded during the period and check that the process was followed for new ones, and the population of vendors terminated and check the offboarding evidence.

The break points are consistent across the companies we work with. The inventory is incomplete because it was built from the accounting export, so anything on a free tier or paid on a personal card is missing. Reviews are dated in a cluster three days before the audit, which tells the auditor the cadence is not real. The DPA on file is the vendor's standard template that was never countersigned. And offboarding, which is the weakest link almost everywhere: the vendor was cancelled, the account was closed, and there is no record of when access was revoked or whether data was deleted, because nobody thought to screenshot anything on the way out.

The fix for the last one is procedural rather than technical. Add a termination checklist with four items: access revoked and evidenced, data export taken if needed, deletion requested in writing, deletion confirmation received. The written deletion request matters even if the vendor never replies, because under PIPEDA your accountability for the information does not end when the contract does, and a documented request is the difference between a controlled exit and an assumption.

Keeping the register, the tiering rationale, and the dated review records in one place is most of the work. If you do not have somewhere to put them, the free traztech Workspace includes a vendor register that produces the dated trail auditors ask for, and it is a better home than a spreadsheet that lives in one person's drive.

When the Vendor Refuses, and What Leverage You Actually Have

You will eventually depend on a vendor that will not sign your DPA, will not provide a report, and will not answer a questionnaire. This is normal, particularly with large platforms that operate on standard terms and with small tools where nobody is staffed to respond. Pretending otherwise produces a TPRM program that quietly excludes the vendors it cannot handle.

The honest options are these. Accept the risk, in writing, with a named owner and a stated reason, and note the compensating controls you run on your side. Reduce the exposure so the tier drops: restrict what data the vendor receives, remove the production access, move the integration behind a proxy that filters what leaves. Or replace the vendor, which is the right answer more often for small tools than founders expect, because the switching cost is usually lower than the review cost. What an auditor wants to see is that a decision was made deliberately and recorded. What fails is a high-tier vendor with an empty diligence file and no explanation.

Leverage runs with contract size and renewal timing. The moment to ask for a DPA, a breach notification window in hours, and a right-to-audit clause is before you sign or at renewal, never in the middle of a term. Founders who put these asks into the initial procurement conversation get them agreed at a rate that surprises people, because the vendor's sales team wants the deal closed and their legal team already has the clauses drafted.

When Not to Buy a TPRM Engagement

If you have fewer than about twenty vendors and one of them is your cloud provider, do not hire anybody for this. Build the inventory yourself in an afternoon from your accounting export plus a list of every OAuth grant in your Google Workspace and code host, tier them with the rules above, collect the reports for the high tier, and file the DPAs. That is a real program and it will pass a first SOC 2 audit. The consulting spend adds nothing at that scale.

If your problem is that questionnaires from your own buyers are eating your week, the answer is not a TPRM program, it is a trust center and a maintained set of standard answers. Those are different projects, and buying the wrong one is a common and avoidable mistake.

Where outside help does earn its cost is when the vendor count is past fifty, when a regulated buyer is auditing your program rather than accepting it, or when you have inherited an environment where nobody knows what the vendors are. That is scoped work with an end date, and it is priced as such on our pricing page rather than sold as an open-ended retainer when a one-time cleanup is what you actually need.