SOC 2 vendor management policy and register

The policy is a page. The register is the artifact an auditor actually reads, and it is the one most companies build in the week before fieldwork.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A vendor management policy for SOC 2 needs to say five things: which third parties are in scope, how each is risk-rated, what due diligence is required at each rating before you onboard, how often vendors are re-reviewed, and what happens when you stop using one. Behind it sits the register, and the register is what gets sampled. If you only have time to do one of the two properly, build the register.

Canadian companies have a second reason to take this seriously. Under PIPEDA, accountability for personal information stays with your organization when you hand data to a processor. You remain answerable for what your subprocessors do with it, which means the contract clause and the review are not audit theatre.

Which third parties belong in the register?

Not all of them. A register listing 90 SaaS subscriptions including the design tool and the office coffee service is unusable and nobody re-reviews it. The test that works: include a vendor if it stores or processes customer data, if it has access to your production environment, or if its failure would take your service down. That usually produces 10 to 25 entries for a company of this size.

Subprocessor

A vendor that processes personal information on your behalf, such as your cloud provider, your email delivery service or your support desk. These need a contract with data protection terms and normally a public list if your own customer agreements promise one.

Critical vendor

One whose outage stops your service. Sometimes the same list, sometimes not: a payment processor may hold no personal data of yours and still be critical.

Everything else

Tools that touch neither customer data nor production. Keep them out of the register and say in the policy why the boundary sits there.

How should we risk-rate a vendor?

Rate on two axes and let the higher one win: the sensitivity of the data the vendor sees, and the impact of it failing. Do not build a weighted scoring model with fifteen inputs, because you will not maintain it and an auditor cannot follow it. Three ratings, each with a named due diligence requirement and a review cadence, is a policy you can keep.

The clause worth writing carefully is the one about what you do when a high-rated vendor has no SOC 2 report. It happens, usually with a small specialist tool. The answer is not to pretend. Write that where no report exists you complete a security questionnaire and record a risk acceptance signed by a named person. That is a defensible control; the questionnaire guide covers what to ask for and what a thin answer looks like.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

A worked register extract

The register needs eight columns and no more: vendor, what it does, data it sees, rating, internal owner, evidence held, date last reviewed, next review due. Below is what the tier counts look like for a typical Canadian SaaS company, with the annual review load that follows from the cadences above.

Roughly a day and a half a year, spread across four quarters, is what a maintained vendor program costs a company this size. That is the number to weigh against the temptation to write "quarterly review of all vendors" into the policy and then do none of it.

Where PIPEDA changes the wording

PIPEDA's accountability principle means an organization is responsible for personal information in its possession or custody, including information transferred to a third party for processing, and must use contractual or other means to provide a comparable level of protection while the information is being processed. That has three consequences for this policy.

1. The policy has to require a written agreement with data protection terms before personal information reaches a processor, not after. Write onboarding so the contract precedes the data.
2. The comparable protection standard is yours to demonstrate, which is why the high-rating due diligence names a report you have actually read rather than a logo on a trust page.
3. Cross-border transfer is permitted under PIPEDA but must be disclosed to individuals, so your register should carry the processing location for each vendor and your privacy notice should match it. If you hold personal information about people in Quebec, Law 25 goes further and expects a privacy impact assessment before transferring personal information outside Quebec, so the policy needs a trigger for that assessment rather than leaving it to memory.

Health data adds a third layer. Under PHIPA a health information custodian remains responsible for its agents, so a company handling Ontario health records should mirror that language in the vendor clause instead of relying on a generic processor sentence. The PIPEDA guide covers the accountability principle in full.

Does your register carry these fields?

0 of 8 done · Reset

• Vendor name and what the service actually does, in plain words.
• The data it sees, specific enough to tell customer personal data from company data.
• Risk rating with a one-line rationale.
• Named internal owner, a person and not a team.
• Evidence held: report type, its period, and where the file lives.
• Contract status, including whether data protection terms are signed.
• Processing location, for the cross-border disclosure question.
• Date last reviewed and date next due, both filled in for every high-rated row.

What gets a vendor management policy turned into a finding?

A register with no review dates. The most common outcome is not a missing policy but a register whose review column is blank for the whole window. The control is the review, not the list, so an unreviewed register fails even though the document is perfect.

"All vendors are reviewed annually." If the register has 40 rows, you have committed to 40 reviews. Either tier the cadence in the policy, as in the table above, or shorten the register. Do not leave a blanket sentence in place and quietly review six of them.

A SOC 2 report on file that nobody read. Auditors ask what you concluded from the vendor's report. Downloading it is not review. Add a short note per vendor recording the report period, whether there were exceptions, and whether any complementary user entity controls apply to you, since those are obligations the vendor is passing back to you.

An expired report. A vendor SOC 2 covering a period that ended 14 months ago does not cover your window. Either get the current one or accept the gap in writing, ideally with a bridge letter from the vendor covering the interval.

Subprocessors missing entirely. The classic omissions are the support desk, the email delivery service, the analytics tool that receives user identifiers and any contractor working through their own company. All of them see customer data. The policy templates page covers what else to cut from an inherited pack, and the policy checklist will tell you whether your vendor content should be standalone or merged with the risk assessment policy. The evidence collection page covers how to hold the vendor reports so they are producible on request.

Common questions