Skip to main content

How-to

How to Perform a Vendor Risk Assessment Using Public Evidence

A step-by-step method for vendor risk assessment that starts with registries, trust centres and subprocessor lists before any questionnaire goes out.

Solomon AmosPublished 27 Oct 20269 min read

Most vendor risk assessments begin with a questionnaire, somewhere between twelve and eighty questions, sent cold to a vendor's security team, followed by a two-week wait for answers that are often already sitting in public view. A faster and more accurate method is to build the assessment from the vendor's own public record first: registry listings, the trust centre, the subprocessor list, and any report metadata the vendor has already disclosed. This does not replace a questionnaire, it narrows it down to the handful of questions public evidence genuinely cannot answer. This guide walks through that method step by step, using the kind of lookup you would run in the bulk vendor security check before drafting anything, and shows where the public record runs out and a direct question is still needed.

What counts as public evidence, and what it does not prove

Public evidence falls into roughly four groups. There are primary registries run by a scheme owner, such as the FedRAMP Marketplace, the CSA STAR registry, the Data Privacy Framework list, and the Visa Global Registry of Service Providers. There are vendor-hosted trust centres, often built on a compliance automation platform. There are subprocessor and sub-service organisation lists published for GDPR or SOC 2 purposes. And there is report metadata, the report type and audit period printed on the cover of a SOC 1 or SOC 2 report. Each of these proves something narrow. A trust centre badge proves a vendor states it holds a framework and usually the date it was last refreshed, not that the underlying report has been read by anyone on your side. A phrase like "SOC 2 certified" is a sign the person writing it does not understand what they are looking at: SOC 2 produces an auditor's report, not a certificate, and the same gap exists with "HIPAA certified", which does not exist either. HIPAA is evidenced by a signed Business Associate Agreement, not a badge. None of this is pedantry, it changes what you can rely on without picking up the phone.

A six-step method using public evidence

  1. 1

    Pull the registry entry first

    Before reading anything the vendor wrote about itself, check the primary registry for any framework it claims: FedRAMP, CSA STAR, DPF or the Visa PCI registry. A registry entry is controlled by the scheme owner, not the vendor, which makes it harder to overstate than a marketing page.
  2. 2

    Read the trust centre literally

    Note the exact framework name, the report type where one applies, the stated scope, and the date the evidence was last refreshed. A framework listed without a date or a scope statement is a claim, not evidence.

  3. 3

    Open the subprocessor list

    Check who the vendor actually sends data to, where those sub-processors are based, and whether the list matches what the main contract or DPA describes. A short, stale subprocessor list is often a sign the page has not been maintained.

  4. 4

    Check regional and sector frameworks separately

    A vendor can be strong on SOC 2 and ISO 27001 and still have nothing for NHS DSPT, TX-RAMP, or a BAA, depending on which sector and region you operate in. Check each one on its own terms rather than assuming one framework implies another.
  5. 5

    Map what remains against your actual obligations

    Not every framework matters equally for every buyer. A payments business cares about the Visa PCI registry validity date far more than a generic security badge; a healthcare buyer cares about a signed BAA more than a HIPAA logo.
  6. 6

    Draft a short questionnaire for the gaps only

    Once the public record is read and scored, write questions only for what is genuinely missing or ambiguous, rather than reusing a generic eighty-item template that repeats what the vendor already states publicly.

Reading the registries without over-trusting them

Public evidence sourceWhat it confirmsWhat it does not confirm
Registry mirror (FedRAMP, CSA STAR, DPF, Visa PCI)A listing existed under a given identity at the point it was checkedCurrent status if the registry has not been rechecked recently, or whether the listing covers the product you are buying
Trust centreFrameworks the vendor states it holds, badge dates, HIPAA badge presenceWhether a HIPAA badge is backed by an executed BAA, or whether a report's scope covers your specific use case
Subprocessor listNamed sub-processors and, often, their locationContractual flow-down terms, or whether the list is complete for every product line a vendor sells
SOC 1 or SOC 2 report metadataReport type, Type I design only or Type II operating effectiveness, and the audit periodAnything about the period after the report's stated end date

What each public source actually proves, and where a direct question is still needed.

Where the public record runs out

The gap between what a vendor states and what a buyer can verify is usually visible on a single page, once you know where to look. The most common pattern across the index is a Data Privacy Framework entry whose status has drifted away from the date printed in the trust centre copy, sitting next to a subprocessor list and a set of SOC 2 and ISO 27001 lines that look complete at first glance. The card below shows exactly this pattern on one vendor's page. Look at how the DPF row is dated against the underlying self-certification record, then compare that to what sits next to it, the public DPA, the subprocessor list, and the stated report types, rather than taking any single badge at face value.

Notion logo

Notion · Trust report

Collaboration · Public evidence as of 1 Nov 2026

Visit trust centreFull evidence

Framework overview

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

3 more frameworks on the evidence page

3Documents and agreements

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

31Subprocessors

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

A lapsed DPF listing sitting next to a public DPA and a long subprocessor list. Every line is a dated public record from Notion's trust centre and the Data Privacy Framework list. A framework not shown means no public evidence was found, not that Notion lacks it.CertReports
Flow diagram showing a vendor risk assessment moving from registry check to trust centre read to subprocessor list check before any questionnaire is sent.
The public evidence review happens before the questionnaire, not instead of it.

Mapping frameworks to the regulations that actually apply to you

A vendor can hold ISO 27001, CSA STAR and a HIPAA badge and still be the wrong evidence for your contract if none of it maps to the regulation actually governing the relationship. A payments business under PCI DSS needs a validity date in the Visa registry, not a general security badge. A healthcare buyer needs a signed Business Associate Agreement, not a HIPAA badge sitting on a trust centre page. A firm inside the scope of DORA or NIS2 needs evidence that maps to incident reporting and concentration risk, which a SOC 2 report was never designed to cover. Since 4 July 2026 a FedRAMP listing should read "FedRAMP Certified" under the Consolidated Rules for 2026, not "Authorized", and "Ready" became a legacy status on 28 July 2026, so a vendor still displaying the old wording is a small signal its trust centre has not been updated. Run the vendor's evidence and your own obligations through check my stack before deciding which gaps are worth chasing with a direct question.

Scoring the gaps you find

Once the public record is read, score what is missing rather than guessing at it. Three figures are worth keeping in view while you do that.

3,000+
vendors with tracked public evidence
in the CertReports index on 2026-10-27
75%
of Visa registry entries are not a PCI DSS validation
in the CertReports index on 2026-10-27
31 Oct 2025
ISO 27001:2013 certificates lapsed under IAF MD 26
transition deadline for the 2022 edition
We publish what a vendor has stated publicly and the date we last checked it. We do not infer a status a vendor has not published, and we do not call a report a certificate.

Turning gaps into a short questionnaire

A questionnaire built after a public evidence review looks very different from one built from a generic template. Instead of eighty questions, it might be six: confirm the BAA covers the specific product in scope, confirm the SOC 2 report period extends past a renewal date, confirm which legal entity holds the DPF self-certification if the parent and a subsidiary differ, and ask for anything genuinely undocumented, such as a named sub-processor's retention period. The questionnaire pre-fill tool does the first pass automatically, pulling answers from captured registry and trust centre evidence so a reviewer only has to check what is left blank. For the whole process condensed into a single sitting, the vendor security review checklist covers the same steps in a shorter format, and comparing vendors side by side is worth doing before the questionnaire goes out, not after, whenever more than one supplier is on the shortlist.

Diagram of a vendor questionnaire with fields pre-filled from captured registry and trust centre evidence, with remaining blank fields flagged for direct follow-up.
Pre-filled answers come from captured evidence, not inference.

Keeping the assessment current

A vendor risk assessment built from public evidence has a shelf life, usually the length of the report period or registry listing it relied on. A SOC 2 Type II report typically covers several months and the assessment built around it goes stale the day that window closes. A DPF self-certification can lapse without the trust centre copy changing. A Visa PCI registry entry carries its own validity date that has nothing to do with when a vendor last edited its marketing page. Set a recheck cadence rather than treating the first pass as final, and check how to check a vendor's subprocessor list on a schedule too, since sub-processor rosters change more often than frameworks do. Re-running the same registry and trust centre check at renewal costs a fraction of the time the first assessment took.

A good habit, not a one-off project

The point of this method is repeatability. Running the same sequence, registry, trust centre, subprocessor list, regulation map, gap list, on every vendor is what makes a comparison across suppliers meaningful rather than anecdotal.

People also ask

What is vendor risk assessment?

A vendor risk assessment is the process of checking a supplier's security, privacy and compliance posture before and during a contract, covering data handling, certifications, sub-processors and incident history. It typically combines public evidence, such as registry listings and trust centre statements, with direct questions where no public record exists, and produces a record a buyer can point to if a regulator or auditor later asks how the vendor was vetted.

What is third party vendor risk assessment?

Third party vendor risk assessment applies the same process specifically to suppliers that touch a business's data, systems or regulated processes, rather than every supplier a company uses. It usually sits inside a wider third-party risk programme and feeds obligations such as SOC 2 vendor management or GDPR processor oversight, which is why it needs to map to the regulation actually governing the relationship, not a generic checklist.

How to perform vendor risk assessment?

Start with what the vendor has already published: registry entries, trust centre claims, subprocessor lists and report metadata such as SOC 2 report type and period. Score what public evidence confirms against what your regulation requires, then send a short, targeted questionnaire covering only the gaps. Set a recheck date tied to the vendor's report period or registry validity date so the assessment does not go stale silently.

How to do vendor risk assessment?

Follow the same sequence every time: pull the primary registry entry, read the trust centre literally rather than taking badges at face value, check the subprocessor list, map what remains against the regulations that actually apply to your business, and only then draft questions for anything undocumented. Repeating this consistently across vendors is what turns individual lookups into a comparable assessment.

vendor risk assessmenttrust centrepublic evidencedue diligencethird party risk
S

Solomon Amos · Founder, CertReports

Solomon builds CertReports, the public evidence index for vendor security reviews. PhD in machine learning and cybersecurity, two years embedded at HMRC digital programmes, founder of TapTax. He writes about what registries, trust centres and auditors actually publish, and how buyers can use it before the questionnaire goes out.

Read next on CertReports

You might also like