How to Get Third-Party Risk Management: A Step-by-Step Guide

To get third-party risk management in place, you inventory every vendor with system or data access, tier them by risk, collect and review evidence like SOC 2 reports, and monitor them on a fixed schedule, usually over four to eight weeks for a first pass. Enterprise buyers and SOC 2 auditors both expect this program to exist and to have paperwork behind it, not just a vendor spreadsheet nobody has opened since onboarding.

Why Third-Party Risk Management Comes Up Now

Most Canadian SaaS companies do not build a formal third-party risk management program because they woke up worried about vendor breaches. They build it because a SOC 2 auditor flagged the gap, or because a US enterprise buyer's security questionnaire asked "how do you assess the security of your subprocessors" and the honest answer was "we don't, really." Both triggers point to the same root cause: every SaaS tool you connect (payment processors, cloud hosting, analytics, support platforms) inherits a slice of your customers' data and your risk. If one of those vendors gets breached, your customers hold you accountable, not the vendor.

SOC 2's vendor management criteria (mapped mostly to CC9.2 in the Trust Services Criteria) does not require you to audit every vendor yourself. It requires you to show you evaluated them, documented the decision, and are watching for changes. That is achievable without an enterprise GRC platform, but it does require a repeatable process, which is where most founder-led teams stall out.

Step 1: Build a Complete Vendor Inventory

Start by listing every third party that touches customer data, production systems, or your codebase. This is broader than most teams expect on the first pass:

• Cloud infrastructure and hosting (AWS, GCP, Azure, and any CDN or edge provider)
• Payment processing and billing
• Customer support and ticketing tools
• Analytics, marketing automation, and email delivery
• Code repositories, CI/CD, and any AI coding or agent tools with repo access
• HR, payroll, and identity providers

Pull this from your SSO provider's connected apps list, your finance team's subscription log, and a quick engineering interview, not from memory. Teams routinely find fifteen to thirty vendors on the first real inventory when they expected eight.

Step 2: Tier Vendors by Risk, Not Alphabetically

Not every vendor needs the same scrutiny. A tiering model saves you from spending three hours reviewing your team calendar app's security posture while your actual payment processor gets a rubber stamp. A workable three-tier model:

• Critical: has access to production data, customer PII, or your core infrastructure (cloud host, database provider, payment processor)
• Moderate: has limited or indirect data access (support tools, analytics platforms)
• Low: no meaningful data access (internal productivity tools)

Critical vendors get a full review before onboarding and annually after. Moderate vendors get a lighter review. Low-tier vendors get a checkbox and a renewal reminder. This tiering decision itself needs to be documented, since auditors will ask how you decided.

Step 3: Collect and Review Evidence

For critical and moderate vendors, request their SOC 2 Type II report (or ISO 27001 certificate), review it for exceptions or qualified opinions, and check that the report period is current, not two years stale. If a vendor has no third-party attestation, a security questionnaire and a review of their public security page and breach history are the fallback. Document what you reviewed and the date, even if the conclusion is simply "acceptable risk, no findings."

This is the step Canadian companies underestimate on timeline. Getting SOC 2 reports out of smaller vendors can take one to three weeks of email follow-up, and some vendors will only release them under NDA. Budget for that lag rather than assuming instant turnaround.

Step 4: Write the Vendor Risk Policy and Contracts

Your policy needs to state the tiering criteria, review frequency, and what happens when a vendor fails review (remediation plan, contract clause, or offboarding). Contracts for critical vendors handling personal data should include data processing terms consistent with PIPEDA, and Quebec Law 25 if you serve Quebec customers, covering breach notification timelines, data location, and subprocessor disclosure. This is also where a documented incident response and breach notification expectation for vendors belongs, since auditors and enterprise security teams both ask for it.

Step 5: Monitor on a Fixed Schedule, Not Ad Hoc

A program that exists only at onboarding is not a program, it is a one-time checkbox. Set a calendar cadence: annual re-review for critical vendors at minimum, with a trigger for off-cycle review whenever a vendor discloses a breach or you read about one in the news. Track SOC 2 report expiry dates the same way you'd track a domain renewal, because a stale report during an audit window is an easy, avoidable finding.

Realistic Timeline for a First-Time Program

• Week 1: vendor inventory and tiering
• Weeks 2 to 4: evidence collection and follow-up with vendors for reports
• Weeks 4 to 6: policy drafting, contract review, remediation of any gaps found
• Weeks 6 to 8: program goes live with monitoring cadence set

That timeline assumes someone is dedicated to chasing vendors for documents, which is usually the actual bottleneck, not the writing.

Where a Partner Actually Helps

Founders and CTOs in Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal tend to hit the same wall: the framework is not hard to understand, but running down twenty vendors for current SOC 2 reports while also shipping product is a full-time distraction. A boutique partner earns its keep in three places: building the tiering logic so it maps cleanly to what your SOC 2 auditor expects, chasing vendor documentation so it does not sit on an engineer's desk for a month, and keeping the monitoring cadence running after the initial push instead of it quietly lapsing. If your compliance work already spans more than vendor risk, our broader compliance advisory work covers how this fits into SOC 2 readiness end to end.

Getting Started

If you are staring at a SOC 2 gap letter or an enterprise questionnaire asking for your vendor risk policy, the fastest path is an inventory and gap review, not a platform purchase. Contact traztech for a straightforward assessment of where your vendor program stands and what it takes to close the gap before your next audit or deal review.

How to actually read a SOC 2 report instead of filing it

Collecting reports is the easy half. Most teams download a vendor's SOC 2 Type II, confirm it exists, drop it in a folder, and record the review as complete. An auditor who asks what you found will get a blank look, and that is a finding.

A Type II report has four sections and only two of them repay careful reading. Section 3 is the system description, where you confirm the report actually covers the service you use. Vendors with multiple products routinely scope the report to one platform, and if you use a different one, the report tells you nothing. Section 4 is the testing detail, where the auditor lists each control, the procedure performed, and the result. This is where exceptions appear. An exception is not automatically disqualifying, and a report with two documented exceptions and clear management responses is often more trustworthy than one with none. What matters is whether the exception touches a control you depend on, and whether management's response describes a fix or a rationalization.

Three things inside those sections cause the most trouble later.

Complementary user entity controls. Near the end of Section 3, most reports list the controls the vendor assumes you are performing. Configuring SSO, provisioning and deprovisioning your own users, setting retention correctly, restricting admin roles. These are obligations transferred to you, and your own auditor may test whether you meet them. Extract the CUEC list for every critical vendor and check it against what you actually do. This takes twenty minutes per vendor and it is the highest-value part of the review.

Subservice organizations and the carve-out method. Most vendors carve out their own infrastructure provider, meaning the report explicitly excludes the controls at that subservice organization. Your payment vendor's SOC 2 may say almost nothing about the cloud platform underneath it. That is normal and usually acceptable, but you should know it, because it is where the fourth-party question comes from.

The period, not the issue date. A report issued last month may cover a period ending nine months ago. If the gap between period end and today is more than three months, ask for a bridge letter, which is a short signed statement from the vendor confirming no material changes since the period closed. Auditors accept bridge letters. They do not accept a stale report with no explanation.

The vendors that break the standard process

AI and LLM vendors. These now sit in almost every stack and the questions are different. Does your data get used for model training, and is that the default or an opt-out. Which model providers sit behind the product, because a wrapper vendor's SOC 2 tells you nothing about the inference provider handling your prompts. Where is inference performed geographically, which matters for PIPEDA and for Law 25 data transfer obligations. What is the retention on prompts and outputs, since many providers retain input for abuse monitoring for thirty days even when they do not train on it. And who at the vendor can read prompt logs. A coding assistant with repository access is a critical-tier vendor by any sensible definition, and it very often gets onboarded by an engineer on a personal card without anyone recording it.

Vendors with no attestation and no intention of getting one. Small specialist tools, contractors, and open-source-backed companies often have nothing to give you. The fallback is not to refuse them. It is to reduce what they can reach and document that decision. Scope the API token to a single repository, put the integration in a non-production account, cap the data it receives, and record in the review that the compensating control is scope limitation rather than vendor assurance. That is a defensible position and it reads far better than an empty review record.

Vendors who are also your customers, or your investors' portfolio companies. The commercial relationship makes people reluctant to push. Push anyway, and route the awkward part through the process rather than the relationship. "Our vendor risk policy requires this for tier one suppliers" is easier to say than "I do not trust you."

Concentration risk, which no questionnaire asks about

Vendor reviews look at each supplier in isolation, so they miss the pattern where six of your critical vendors all run on the same cloud region, or where your monitoring, alerting, and status page all depend on a single provider that would be down during exactly the incident you need them for. Nothing about any individual vendor looks wrong. The aggregate does.

Once a year, look at the inventory as a portfolio rather than a list. Which single vendor failure takes the product down. Which single vendor failure takes down your ability to respond to the outage. Which vendors hold a copy of the same customer data. You will not necessarily act on the answers, because dual-sourcing infrastructure is expensive and usually the wrong call for a company under a hundred people. But knowing it is a risk decision you made deliberately is materially different from discovering it during an outage, and it is the kind of answer that impresses an enterprise reviewer.

Offboarding, which is where most programs quietly fail

Onboarding gets attention because it blocks something. Offboarding blocks nothing, so it does not happen. The result is a long tail of API tokens, OAuth grants, SAML integrations, and cross-account roles belonging to tools nobody has used in two years. Each one is a live path into your environment held by a company you no longer have a relationship with, and cancelling the subscription does not revoke any of it.

A workable offboarding checklist is short. Revoke the API tokens and OAuth grants from your side rather than trusting the vendor to disable them. Remove the SAML or SSO application. Delete any cross-account IAM role or service account created for the integration. Request written confirmation of data deletion, and note the contractual retention period the vendor is allowed to keep, which for backups is often thirty to ninety days. Record the date and who did it. Then mark the vendor inactive in the inventory rather than deleting the row, because your auditor may sample a vendor you stopped using and ask how it ended.

When a vendor gets breached

The first thing that happens is that you find out from a news article or a customer, not from the vendor. Plan for that. The second thing is that your own customers email you within hours asking whether their data was involved, and the quality of your answer over the following day sets the tone for the whole incident.

The work itself is straightforward if the inventory is current. Establish what data that vendor holds and for which customers, which your inventory should already tell you in minutes rather than days. Rotate every credential shared with them, including API keys, webhook secrets, and any SSO configuration. Pull your own logs for that integration to see whether anything anomalous came through it. Open a direct line to the vendor and ask for specifics rather than the press statement. Then assess your own notification obligations, which under PIPEDA turn on real risk of significant harm and under Quebec's Law 25 carry their own timelines and record-keeping requirement, including a breach register you are expected to maintain whether or not you notify.

The single artifact that makes this survivable is a current inventory with data mapping attached. Teams that have one answer their customers the same afternoon. Teams that do not spend three days reconstructing which systems that vendor touched, and their customers notice the silence. If containment help is what you need in the moment, that is part of what our retained and incident response work covers.

When you should not buy this from us, or from anyone

If you have fewer than fifteen vendors and one person who genuinely knows all of them, build this yourself. A spreadsheet with vendor name, tier, data accessed, evidence reviewed, review date, and owner satisfies the SOC 2 criteria completely. The standard does not require software, and no auditor has ever preferred a platform to a well-maintained sheet. Our free Workspace will hold the register and the evidence if you want somewhere structured to put it, and it costs nothing.

Do not buy a third-party risk platform as your first move either. The platforms are good at continuous monitoring and questionnaire workflow at scale, and they are consistently oversold to companies whose actual problem is that nobody has written down which vendors exist. Automated security ratings in particular tend to produce a letter grade based on external scanning that says very little about whether a vendor handles your data properly, and enterprise reviewers know it. Build the register, run one full review cycle manually, and then decide whether the pain you experienced is the kind software fixes.

Where outside help earns its fee is narrower than the market suggests. Chasing twenty vendors for current reports while shipping product. Reading those reports properly, particularly the CUECs and the exceptions. Making the tiering logic defensible to a specific auditor who has already given you a gap letter. Getting a stalled deal unstuck when a buyer's security team has raised a vendor concern you cannot answer. If that is your situation, our compliance work covers it and our fixed-scope pricing means you know the number before you start. If your situation is that you have never written the list down, do that first and call us afterwards if it still hurts.