Vendor Risk Assessment Template

Verizon's 2026 Data Breach Investigations Report found third-party involvement in 48% of breaches¹, a 60% rise on the year before. Before you open anything the vendor sent, write down three things:

• What you will send: records, fields, rough volume and route, such as an API or file upload
• What they can reach without being sent anything: admin consoles, their support staff, tools that let them view a user's session
• What breaks if they go down or get something wrong

Be specific. "Customer data" gives you nothing to check, while "name, work email and ticket text, about 4,000 a month, over their API" does. Watch the second line: standing access never appears on a data flow diagram, yet it can reach everything your users see.

Let that picture set how deep you go. NIST's Cybersecurity Framework 2.0 includes suppliers known and prioritized by criticality² among its outcomes. A payroll provider holding bank details needs the full review. A design tool that never sees customer data needs a short one.

Turn those notes into reliance points: one line for each thing you depend on, written so it can be proved true or false. Tag each with its trust services category, since that decides whether the report can answer it.

The vendor's management chooses which categories its SOC 2 covers³. Every SOC 2 tests the common criteria, the core security controls such as access and change management, but availability, processing integrity, confidentiality and privacy are optional.

Expect 20 to 35 lines for a vendor holding sensitive data. Fewer than 10 usually means the flow was described too loosely.

Write the list before you read the report, or it will mirror the vendor's scope back at you. US bank regulators' 2023 third-party guidance frames the question well: whether the scope and the results of SOC reports are relevant⁴ to the vendor's work.

Ask the vendor for its SOC 2 Type 2 report, any bridge letter and its current list of subprocessors, the companies that handle your data for it. A SOC 3 won't do, because it leaves out the system description and the auditor's tests³.

A Type 1 report covers only whether controls were suitably designed as of a point in time³. A Type 2 also tests whether they operated effectively throughout a period, and lists the tests and results. Read it in this order:

1. 1

   The opinion

   Note the period, the categories covered and whether the vendor's own suppliers are in scope. Any reliance point in a category the vendor left out stays unanswered.

2. 2

   The system description

   Find the subservice organizations (the report's term for those suppliers) and compare them with the subprocessor list. Under the carve-out method, their systems are excluded from the description and the scope of the examination³, so mark every line that depends on one.

3. 3

   The test results

   Microsoft, explaining its own SOC 2 reports, says most examinations have some observations⁵, so expect deviations. Keep each rate intact, such as 3 of 25 sampled departing employees keeping access too long, and check which land on your list.

4. 4

   The complementary user entity controls

   These are controls the vendor assumed its customers would run³, such as enforcing multifactor sign-in. The auditor's opinion assumes they work, so any you haven't set up are gaps on your side.

Give every reliance point one status: tested clean, deviation, carved out, waiting on a control of yours, or out of scope. Note the report section and page beside it. Any line the report doesn't address is unanswered, never clean, and goes on your questionnaire.

Coverage is the tested-clean lines over the total, written next to the opinion. The next reader can check a fraction like 18 of 30, but not a "medium risk" label.

Last, do the date arithmetic. A Type 2 describes a period that has already ended. A bridge letter covers part of the gap since, but only on the vendor's word. Microsoft calls its own bridge letters self-attestations, not reports based on examinations by the auditor⁵. Record the days since the audited period ended and the days with no coverage at all.

Sort the gaps by who has to act. Deviations you rely on become dated questions to the vendor. A carved-out supplier with no evidence becomes a request for its own report, or for written proof that the vendor's promises to you bind it.

The bank regulators' guidance also suggests contracts address when the vendor must tell you about a new subcontractor⁴. A one-page contract summary shows whether yours does.

User entity controls you haven't set up are your work, not the vendor's, such as turning on single sign-on or adding the tool to your employee offboarding checklist.

Then decide: approved, approved with conditions, approved for a limited scope, or declined. Give each condition an owner and a date. Time the re-review to the vendor's next report, not the contract anniversary, since that report is your next independent evidence. In the US, the FTC's Safeguards Rule requires the financial businesses it covers to oversee service providers, including periodically assessing them based on the risk they present⁷.

Once the vendor is live, track what it delivers with a vendor performance review. To start faster, open this template with Edit with AI: River turns your data flow into reliance points before reading the vendor's report.