How to Do Third Party Risk Management With Public Evidence

Third party risk management is the discipline of finding out what your vendors actually do with your data and your money, then watching for when that changes. Most programmes do not fail because nobody wrote a policy. They fail because nobody kept the evidence current after the first review, so a SOC 2 report from two years ago sits in a shared drive while the vendor's actual posture has moved on. This guide sets out a tiering and monitoring workflow built around public evidence, trust centres, registry mirrors and the compliance artefacts vendors already publish, mapped to specific tools rather than handed over as a generic policy template.

The five-step workflow in brief

The approach below treats evidence as something that decays, not something you collect once and file. Each step maps to a concrete action you can take this week, not a theoretical control objective. If you want the background definitions first, what third party risk management actually covers is a useful companion piece.

1. 1

   Tier every vendor before you ask for anything

   Sort vendors by data access and business impact, not by contract size. A payroll processor and a design tool both cost money but carry different risk.

2. 2

   Pull public evidence first, questionnaire second

   Check what a vendor has already published before sending a 200-question form that duplicates it.

3. 3

   Score what you find against the framework that applies

   A HIPAA badge and a signed BAA are different things. Score against the regulation that actually governs the data, not the badge on the homepage.
4. 4

   Set a monitoring cadence by tier

   Critical vendors get checked monthly against expiring certificates and lapsed listings. Low-risk vendors get checked annually.

5. 5

   Decide where automation fits and where it does not

   Compliance platforms help a vendor produce evidence. They do not replace your review of what a counterparty actually publishes.

Step 1: build a tiering model before you collect a single document

Tiering is the step most programmes skip, and it is the one that makes everything downstream cheaper. A vendor that stores protected health information or processes card payments needs continuous evidence. A vendor that only receives your company name and a billing email does not need the same workload. Before you send a single questionnaire, sort your vendor list using three questions: what data can this vendor touch, what happens if it is unavailable for a day, and what happens if its own vendors fail.

• Tier 1, critical: handles regulated data (health, card, financial) or sits on a critical operational path.
• Tier 2, important: handles business data or credentials but not regulated categories, or is a single point of failure for a non-critical process.
• Tier 3, standard: limited data access, easily replaced, no regulated data in scope.
• Tier 4, minimal: no meaningful data access, for example a vendor providing office supplies or a marketing tool with no customer data.

Run your current vendor list through Check my stack first. It flags which regulations actually apply to your business and which of your existing vendors have published evidence against them, which gives you a working tier list in minutes rather than a week of manual spreadsheet building.

Step 2: pull public evidence before you send a questionnaire

Most vendors above a certain size now publish a trust centre with SOC 2 letters, ISO certificates, a subprocessor list and privacy framework status. Reading that first changes what you actually need to ask. If the trust centre shows an active SOC 2 Type II report, a current ISO 27001 certificate and a public Data Processing Agreement, your questionnaire should focus on the gaps, not restate what is already answered. How to read a trust centre covers the mechanics of this in ten minutes.

For the questions that remain, use Questionnaire pre-fill to generate answers sourced from a vendor's public evidence before you send a form at all. This does not remove the need for a signed questionnaire on regulated engagements, but it stops you asking a vendor to retype information that is already sitting on their own security page, and it gives you a documented source for every answer rather than a vendor's unverified assertion.

Step 3: score evidence against the framework that actually applies

A framework badge only matters if it maps to a regulation or contract clause you are actually subject to. A vendor with CSA STAR but no SOC 2 might be fine for a non-critical SaaS tool and inadequate for a payment processor. The table below is a starting scoring matrix by tier, it is not exhaustive and should be adjusted to your sector.

Step 4: set a monitoring cadence instead of an annual review

An annual review catches a problem roughly a year after it starts. Certificates lapse, DPF listings go inactive, and ISO 27001 certificates issued against the 2013 edition stopped being valid on 31 October 2025 under IAF MD 26, yet a vendor's marketing page can keep citing them for months. The fix is not a bigger spreadsheet. It is a recurring check against evidence that is about to expire.

Evidence expiring this month lists certificates, reports and registry listings that are due to lapse across the index, which is the fastest way to know which of your Tier 1 and Tier 2 vendors need a renewal chase before the gap opens, rather than after a customer or auditor notices.

Monthly

recommended check frequency for Tier 1 vendors

in the CertReports index on 2026-11-03

31 Oct 2025

date ISO 27001:2013 certificates lapsed under IAF MD 26

mandatory transition deadline

4 Jul 2026

date FedRAMP's official label changed to "FedRAMP Certified" under the Consolidated Rules

Ready became legacy status on 28 July 2026

A trust centre's own card is a good illustration of why this cadence matters more than a one-off review. Look at the status line next to each framework rather than just whether a badge exists, and check the date attached to any data transfer mechanism, because a listing can sit on a page long after it has gone inactive.

Notion · Trust report

Collaboration · Public evidence as of 3 Nov 2026

Visit trust centreFull evidence

Framework overview

CertReports state for each framework with public evidence: 11 vendor-stated, 1 expired.

• DPFExpiredListing inactive
• HIPAAVendor-statedBadge only, BAA not captured
• SOC 2Vendor-statedType II report
• GDPRVendor-statedTrust centre · 3 Nov 2026
• PCI DSSVendor-statedTrust centre · 3 Nov 2026
• ISO 27001Vendor-statedTrust centre · 3 Nov 2026
• ISO 27701Vendor-statedTrust centre · 3 Nov 2026
• SOC 3Vendor-statedTrust centre · 3 Nov 2026
• ISO 27017Vendor-statedTrust centre · 3 Nov 2026

3 more frameworks on the evidence page

3Documents and agreements

Legal and review documents Notion publishes or offers, as of 3 Nov 2026.

• Data processing agreement · Public
• Subprocessor list · Public
• Privacy policy · Public

31Subprocessors

Named on Notion's public subprocessor list, last seen 3 Nov 2026.

• Anthropic
• AssemblyAI
• AWS
• BABaseten
• BRBrowserbase
• CSCerebras Systems Inc.
• CICinder
• Cloudflare
• and 23 more on the evidence page

Step 5: decide where automation platforms fit

Compliance automation platforms like Vanta, Drata and Secureframe help a vendor produce and maintain its own evidence. They do not replace your review of what a counterparty publishes, and a platform badge on a trust centre tells you how the evidence was generated, not whether it is current or scoped correctly for your use case. Compliance automation platforms compared is worth reading if you are also evaluating one of these tools for your own organisation, since the same platforms that help vendors demonstrate controls can help you run your internal TPRM evidence collection.

Organizations are responsible for assuring the integrity, security, resilience, and quality of their products and services throughout their lifecycle, including the supply chain used for those products and services.

Common mistakes that undermine a TPRM programme

• Writing that a vendor is "SOC 2 certified": SOC 2 is an auditor's report, not a certificate, and the phrase signals the report was never actually read.
• Treating a HIPAA badge on a trust centre as proof of compliance when no signed BAA exists between the two parties.
• Citing an ISO 27001 certificate without checking the edition; a 2013 certificate lapsed on 31 October 2025 and should have been reissued against the 2022 controls.
• Running the same questionnaire depth across every tier, which wastes Tier 3 and Tier 4 review time and still misses gaps in Tier 1 vendors.
• Reviewing evidence once at onboarding and never again until the contract renews, by which point a certificate may have lapsed for a year.

Writing the policy down

Once the workflow is running, the policy document should describe what you actually do, not what a template says every company should do. It should name the tiers, the minimum evidence per tier, the verification sources (trust centre, registry mirror, signed agreement) and the cadence for each. It should also name who chases a lapsed certificate and within how many days. A short, accurate policy that matches your real process survives an audit far better than a long one copied from elsewhere. A 30-minute vendor security review using public evidence is a good reference for the individual review steps to describe inside that policy.