Third-party and vendor review policy template

Third-party and vendor review policy

[ORGANISATION] · approved by [ROLE] · [DATE] · review annually

1. Purpose and scope

This policy governs how [ORGANISATION] selects, approves, contracts with and monitors any third party that stores, processes, transmits or can access our data or connect to our systems. It applies to software bought on a subscription as much as to a signed master services agreement, and to free tools as much as to paid ones. There is no spend threshold below which this policy stops applying, because there is no spend threshold below which the law stops applying.

2. Nothing is engaged without a review

No one at [ORGANISATION] may share personal or confidential information with a third party, or grant a third party access to our systems, until the review in section 4 is complete and [ROLE] has approved it. That includes trials, pilots, proofs of concept and anything signed up for with a corporate card.

Where a tool has already been adopted without review — and in most organisations several have — it is brought into this process rather than quietly tolerated. [PRIVACY LEAD] runs a discovery exercise at least annually against expense records, single sign-on logs and outbound network data to find them.

3. Tiering

Not every supplier deserves the same scrutiny. Each is placed in one of three tiers at the point of request, and the tier drives everything after it.

• Tier 1 — critical. Holds personal information about our customers or employees, or holds sensitive business information, or has privileged access to our systems, or an outage stops us operating. Full review, annual re-review, named owner.
• Tier 2 — important. Holds limited business information, or an outage disrupts but does not stop us. Short-form review, re-reviewed every two years.
• Tier 3 — low. No access to our data or systems. Recorded in the register, no review beyond that.

Tiering is decided on what the supplier can reach, not on what we pay them. Some of the highest-risk suppliers in a typical organisation are inexpensive.

4. What we ask, and what we accept as an answer

For every Tier 1 supplier, before signing:

• What data, and where. Exactly what personal information they will hold, in which countries it is stored, processed and backed up, and which of their own subcontractors will touch it.
• Evidence, not assertions. A current SOC 2 Type II report, ISO 27001 certificate with its statement of applicability, or an equivalent independent assessment. A completed questionnaire signed by their sales team is not evidence. Where a supplier has none of these, that is not automatically a refusal — it is a finding that goes to [ROLE] with the risk stated plainly.
• Breach notification. A contractual commitment to notify [PRIVACY LEAD] within [24 hours] of becoming aware of any incident affecting our data, with enough detail for us to run our own assessment. Our obligation to report to the regulator is triggered by their incident, on our clock.
• Access and authentication. Multi-factor authentication on every account, single sign-on where available, and a named process for removing access when our people leave.
• Sub-processors and AI. Whether our data is used to train any model, whether it is passed to any AI service, and whether we are notified before a new subcontractor is added. Where the answer to training is yes, the default answer from us is no.
• Exit. How we get our data back, in what format, and how their copies are destroyed. Agreed before we sign, because it is unobtainable afterwards.

5. Information leaving Quebec

Where the personal information concerns people in Quebec and will be communicated outside the province, Law 25 requires an assessment before it goes. That assessment weighs the sensitivity of the information, the purposes it will be used for, the protection measures — contractual included — that will apply to it, and the legal framework of the place it is going. The information may only be communicated if the assessment establishes it will receive adequate protection in light of generally recognised privacy principles, and the arrangement must be recorded in a written agreement.

[PRIVACY LEAD] holds these assessments. They are dated, they name who did them, and they are redone when the supplier changes where the data lives.

6. Regulated entities

Where [ORGANISATION] is federally regulated, OSFI Guideline B-10 applies to third-party arrangements. It expects the depth of our due diligence to scale with the criticality of the arrangement, that we understand and manage risk in the chain beneath our supplier, and that we consider concentration — the risk that several critical arrangements rest on the same provider without anyone having noticed. Delete this section if it does not apply to you; do not delete it because it is inconvenient.

7. The contract

Every Tier 1 and Tier 2 agreement states, in writing: what the supplier may and may not do with our data; that they will not use it for their own purposes; the breach notification obligation and its timing; the security standard they will maintain; our right to audit or to receive their independent assessment reports; restrictions on subcontracting; and what happens to our data when the contract ends.

Where a supplier will not accept these terms, that is a commercial decision for [ROLE] to make with the risk in front of them, recorded in the register. It is not a decision for whoever happened to be buying the software.

8. The register

[ROLE] maintains a single register of every third party, listing: the supplier, what they do for us, their tier, the data they hold, where it is held, the contract owner and end date, the date of the last review, the evidence we hold and when it expires, any accepted risks and who accepted them, and the date access was removed if the relationship has ended.

If [ORGANISATION] cannot produce this register within an hour of being asked, it does not function as a control. A spreadsheet that is current beats a platform that is not.

9. Ongoing monitoring

Tier 1 suppliers are re-reviewed annually, and immediately on any of: a publicly reported breach at that supplier, a change of ownership, a change to where our data is stored, or a material change to the service. [PRIVACY LEAD] tracks expiry dates on certifications so that a lapsed SOC 2 is noticed by us rather than mentioned by a regulator.

10. Ending a relationship

When a supplier relationship ends, [ROLE] confirms in writing that our data has been returned or destroyed, revokes every account and integration including service accounts and API keys, and records the closure in the register. Access that was never removed is one of the most common findings we make.

This policy is reviewed annually and after any incident involving a third party.