What Is Third-Party Risk Management (TPRM)? A Practical Guide

Third party risk management is usually explained as a lifecycle diagram: onboarding, assessment, monitoring, offboarding, repeat. That is accurate but it skips the part that actually takes the time. Third party risk management, or TPRM, is the discipline of working out what could go wrong if a vendor is breached, fails an audit, or loses a certification, and then collecting enough evidence to decide whether that risk is acceptable. In practice that evidence is a short, specific list: a SOC 2 report, a subprocessor list, a signed data processing agreement, sometimes a HIPAA business associate agreement, sometimes a FedRAMP authorisation. This article works through that list artefact by artefact, states what each one actually proves, and shows how much of it is already sitting in public trust centres and registries rather than behind a sales rep's inbox.

What third party risk management actually means

TPRM covers any vendor, supplier or partner that touches your data, your systems or your customers. It is not limited to software vendors: a payroll processor, a law firm, a cloud host and a marketing agency all sit inside the same programme because each one creates a point where your organisation's risk depends on someone else's controls. The management part is the ongoing bit. A single questionnaire at signing is a procurement step, not a risk management programme. Proper TPRM tracks a vendor's posture for as long as the relationship lasts: does its SOC 2 report still cover the period you rely on, has its ISO 27001 certificate been reissued under the current edition, is its subprocessor list still accurate and current.

The evidence stack: six artefacts a reviewer actually collects

Strip away the policy language and a TPRM review comes down to checking a fixed set of documents against a fixed set of questions. The table below is close to what a reviewer following a 30-minute vendor security review checklist actually opens, roughly in the order they open it.

How much of that evidence is already public

The honest answer, going by what has actually been indexed, is more than most buyers assume, but unevenly. Trust centres built on platforms such as Vanta or Drata have made framework badges and subprocessor lists visible by default, which has shifted a meaningful share of a TPRM review earlier, before a single email is sent. What stays gated is the SOC 2 report itself, usually behind an NDA, and the signed DPA or BAA, which are bilateral contracts rather than publications. The index statistics page tracks how that split moves month by month.

63%

of reviewed vendors have at least one framework badge or registry listing visible on a public trust centre

in the CertReports index on 2026-11-02

1 in 5

vendors publish a dated, named subprocessor list rather than a generic statement

in the CertReports index on 2026-11-02

41%

of Data Privacy Framework listings checked were active rather than lapsed or inactive against the registry

in the CertReports index on 2026-11-02

SOC 2 reports: the artefact everyone asks for and few read properly

A SOC 2 report is the most requested document in TPRM and the most frequently misdescribed. There is no pass or fail, no certificate, and no such thing as "SOC 2 certified": a SOC 2 is a report, issued by an auditor, describing controls at a point in time or over a review window. How to read a SOC 2 report walks through the sections that actually matter, and the difference between a Type I and a Type II is worth confirming before the report is accepted as evidence of anything beyond design. A trust centre badge that says 'SOC 2' with no report type attached tells a reviewer almost nothing on its own.

Subprocessor lists, DPAs and the Data Privacy Framework

The privacy side of TPRM runs on a separate set of documents. A data processing agreement sets out what a vendor is contractually allowed to do with personal data under GDPR, and it usually names or links to a subprocessor list, the vendors the vendor itself relies on. Checking a vendor's subprocessor list for a change notice period and a current revision date is a five-minute task that most reviewers skip entirely. For transfers out of the EU, a Data Privacy Framework listing is the mechanism to check directly against the registry, because the registry is where status actually changes, not the badge sitting on a marketing page.

Notion's trust centre is a reasonable illustration of this layer. Rather than quoting figures here, look at how its Data Privacy Framework listing sits next to a dated data processing agreement and a numbered subprocessor list, and compare that against the SOC 2 Type II and ISO 27001 lines stated separately on the same page. The DPF status itself is worth checking live against the registry rather than trusting a cached badge.

Notion · Trust report

Collaboration · Public evidence as of 2 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 · 2 Nov 2026
• PCI DSSVendor-statedTrust centre · 2 Nov 2026
• ISO 27001Vendor-statedTrust centre · 2 Nov 2026
• ISO 27701Vendor-statedTrust centre · 2 Nov 2026
• SOC 3Vendor-statedTrust centre · 2 Nov 2026
• ISO 27017Vendor-statedTrust centre · 2 Nov 2026

3 more frameworks on the evidence page

3Documents and agreements

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

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

31Subprocessors

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

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

Where the evidence actually lives: trust centres and registries

Most of what a TPRM review collects now sits in one of two places. The first is the vendor's own trust centre, a page built on a compliance automation platform that lists frameworks, badges and sometimes the subprocessor list. Reading a trust centre properly means distinguishing a stated framework from a verified one, because a trust centre is marketing copy with evidence attached, not the evidence itself. The second is the regulator or scheme registry: the FedRAMP Marketplace, the CSA STAR registry, the Visa PCI DSS registry, the DPF registry. These are the only places a claim can be checked independently of the vendor's own page, which is also why compliance automation platforms that generate trust centres do not themselves verify anything; they display what the vendor uploaded.

A practical TPRM workflow using public evidence first

1. 1

   Pull what is already public

   Before sending a questionnaire, run the vendor through a bulk vendor security check, following the same method as a vendor risk assessment using public evidence.
2. 2

   Match evidence to the regulation that applies

   Confirm what GDPR, HIPAA or PCI DSS actually requires of this specific relationship before asking for anything beyond that, rather than running a generic checklist against every vendor.
3. 3

   Verify, do not just collect

   Check the DPF listing, FedRAMP Marketplace entry or ISO certificate against its registry rather than the trust centre badge, and confirm the SOC 2 report type and the period it covers.

4. 4

   Close the gap with a targeted questionnaire

   Ask only for what is not already public: the signed DPA, a BAA if protected health information is involved, or the full SOC 2 report under NDA.
5. 5

   Track expiry, not just approval

   Set a reminder against the report's period end date and the certificate expiry date, and watch for drift rather than waiting for the next renewal cycle to notice a lapse.

TPRM frameworks and what they actually ask for

A TPRM framework is a structured way of running the assessment rather than a certification in itself. NIST Special Publication 800-161 and ISO 27036 both describe a lifecycle of due diligence, contractual controls, ongoing monitoring and exit planning, and banking regulators have written versions of the same idea into supervisory guidance for decades. The common thread across all of them is that outsourcing an activity does not outsource accountability for it.

A bank's board of directors and senior management are responsible for managing activities conducted through third-party relationships, and for identifying and controlling the risks arising from them, to the same degree as if the activity were performed within the bank itself.

Common mistakes that undermine TPRM programmes

• Treating a trust centre badge as equivalent to a verified registry entry rather than a claim that still needs checking.
• Accepting a HIPAA badge as proof a business associate agreement has been signed; a badge is not a contract and the two should never be used interchangeably.
• Describing a vendor as "GDPR certified" when GDPR has no certification scheme at all; the actual evidence is a signed DPA plus documented technical and organisational measures.
• Calling a vendor "non-compliant" when the real issue is that evidence simply has not been published yet; the accurate description is no public evidence, not a compliance failure.