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. And if you're pursuing a public-sector or defence-adjacent contract, the emerging Canadian Program for Cybersecurity Certification (CPCSC) will bring its own supply chain expectations, closer in spirit to CMMC than to SOC 2. 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.