Vendor Risk Assessment: Risk Rating and Template

A vendor risk assessment is the structured review you run on a single supplier to decide what data and access it should get, how much diligence it deserves, and when you will check again. The output is not a score for its own sake. It is a tier, a documented decision, a named owner and a review date, which together are what a SOC 2 or ISO 27001 auditor asks to see.

Most teams get the first assessment right and the twentieth wrong. The first one is careful because somebody is paying attention. By the twentieth, the questionnaire has become a formality, nobody reads the SOC 2 report they collected, and the review dates have quietly passed. This is a walkthrough of the version that survives contact with a real vendor list: a rating model you can apply in ten minutes per supplier, the questions worth asking, the documents worth collecting, and the columns your template actually needs.

What is a vendor risk assessment?

A vendor risk assessment is a documented evaluation of the risk a third party introduces to your data, your operations and your compliance obligations. You run it before onboarding and then on a repeating cycle. It answers four questions: what will this vendor be able to reach, how likely is that to hurt us, what has the vendor done to protect it, and what have we contractually required of them.

It is narrower than third party risk management, which is the whole program: the register, the tiering policy, the cadence, the reporting. The assessment is the unit of work inside that program. If you are setting up the program rather than assessing one supplier, start with the vendor risk management process and come back here for the per-vendor mechanics.

The vendor risk rating model that actually scales

The single decision that determines whether a program survives is how you tier. Rate by what the vendor can reach, not by what you pay it. The cheapest tool on the list is frequently the one holding an API key into production, and the most expensive is often a professional services firm that never touches a system.

Three tiers is enough for almost every company under 200 people. Four is defensible. Five is a spreadsheet nobody fills in.

The written note on the low tier is not busywork. It is the artifact that turns "we did not assess 180 vendors" into "we applied a documented risk-based approach", which is the difference between a defensible program and a finding.

What is a vendor risk rating?

A vendor risk rating is the score or tier you assign a supplier after weighing what it can access against how well it protects it. Internally it is usually a simple inherent-risk tier adjusted for the controls the vendor evidences. Externally, security ratings platforms like UpGuard, Bitsight and SecurityScorecard publish a continuously updated score based on outside-in scanning, which is a different thing and answers a different question.

Both are useful and neither replaces the other. An external rating tells you what the vendor looks like from the internet this week. Your internal tier tells you how much it would cost you if that vendor failed, which no scanner can know.

Vendor risk assessment template: the columns that matter

You do not need forty fields. You need the ones somebody will actually maintain and an auditor will actually read. These twelve carry the whole assessment:

• Vendor name and what it does in one plain sentence, so a new hire understands it without opening the contract.
• Internal owner. A person, not a team. Teams do not chase renewals.
• Data accessed. Customer data, employee data, PHI, cardholder data, or none.
• System access. None, read-only, admin, or production credentials.
• Inherent risk tier from the table above, with the reason in a sentence.
• Assurance held. SOC 2 Type 2, ISO 27001, both, or nothing, with the report date.
• Questionnaire status and date. Sent, returned, reviewed by whom.
• Contract protections. DPA, BAA, security addendum, breach notification window.
• Insurance. Certificate on file and its expiry date.
• Residual decision. Approved, approved with conditions, or rejected, and by whom.
• Next review date. The field that quietly makes or breaks the program.
• Evidence location. Where the report, questionnaire and contract actually live.

Notice that half of those are dates and owners rather than risk analysis. That is deliberate. In practice the assessments are rarely wrong. The reviews are just late.

What should a vendor security questionnaire ask?

Keep it proportional to tier. A 300 question standardized questionnaire sent to a 6 person startup produces 300 guesses, and everyone involved knows it. For a critical vendor without a SOC 2 report, ask about the areas where a failure would actually reach you:

• Where is our data stored and processed, and is any of it outside the United States?
• Is data encrypted in transit and at rest, and who holds the keys?
• How do your staff authenticate, and is MFA enforced on admin access?
• Who at your company can access our data, and how is that access reviewed and revoked?
• Do you use subprocessors, and can we see the list?
• When did you last run a penetration test, and can we see the summary?
• What is your incident response process and your breach notification commitment to us?
• What are your recovery point and recovery time objectives, and when were they last tested?
• Do you carry cyber liability insurance, and at what limit?

If a vendor already holds a current SOC 2 Type 2 or ISO 27001 certificate, most of that is already answered and re-asking it burns goodwill. Read the report instead. Sending and answering these at volume is its own workload, which is what security questionnaire automation exists to reduce.

What documents should you collect from a vendor?

For a critical vendor, five artifacts do most of the work. A current SOC 2 Type 2 report or ISO 27001 certificate with a scope statement you have actually read. A completed questionnaire, dated, with the name of whoever reviewed it. A data processing agreement, or a business associate agreement where PHI is involved. A certificate of insurance showing cyber liability at a limit that means something relative to your exposure. And a named security contact who is not a generic support address.

Insurance certificates are the ones that rot fastest, because they expire on their own schedule and nobody is watching. Teams with a lot of contractors or on-site suppliers usually end up running certificate of insurance tracking as its own workflow rather than as a column in the vendor sheet, for exactly that reason. The security artifacts have the same problem in slower motion: a SOC 2 report covers a defined period, and once that period is more than about fifteen months behind you, it is a historical document rather than assurance.

Collecting the SOC 2 is the easy half. Reading it is where the value is, and the parts that change your own work are the exceptions in Section 4 and the complementary user entity controls, which are tasks the report is quietly assigning to you. Our walkthrough on how to read a SOC 2 report covers what to look for and what a qualified opinion actually means.

Do you need a vendor risk assessment for every vendor?

No. Frameworks expect a risk-based approach, which explicitly means unequal effort. Assess in proportion to what the vendor can reach. A payroll processor holding every employee record earns a full assessment and an annual review. A stock photo subscription earns a register line and a sentence explaining why it goes no further.

What is not defensible is silence. An unassessed critical vendor with no recorded reasoning reads to an auditor as an oversight, not a decision. The reasoning is the control.

How often should you reassess vendors?

Annually for critical vendors, every 18 to 24 months for moderate, and at renewal or scope change for low. On top of the cycle, three events should trigger an off-schedule reassessment: the vendor discloses a breach, the vendor is acquired, or your use of it changes materially, which usually means it just got access to something it did not have before.

That last trigger is the one nobody catches, because it happens through a config change rather than a contract. A tool onboarded as a read-only reporting integration ends up with write access eighteen months later and the assessment still describes the old scope.

What do auditors actually check?

Vendor risk shows up in every framework a growing US software company is likely to face, and the tests are more similar than the wording suggests.

• SOC 2: criterion CC9.2 covers assessing and managing risks from vendors and business partners. Auditors ask for the inventory, the tiering logic, and evidence that reviews happened on the stated cadence.
• ISO 27001: Annex A controls A.5.19 to A.5.22. A.5.22 is the one that catches teams, because it asks for evidence you monitor and re-review suppliers over time rather than just onboarding them carefully.
• PCI DSS v4.0.1: Requirement 12.8 governs third party service provider relationships, including a written agreement acknowledging their responsibility for cardholder data.
• HIPAA: a business associate agreement is required before a vendor handles PHI, and the underlying risk analysis at 45 CFR 164.308(a)(1)(ii)(A) is a Required implementation specification.
• GDPR: Article 28 sets what must be in a processor contract and requires processors to be selected on the basis of sufficient guarantees.

One well-run assessment satisfies all five, which is the argument for mapping the evidence once instead of repeating the exercise per framework. That is what control mapping across frameworks is for.

Where vendor risk assessments go wrong

• Assessing at onboarding and never again. The first review is always the best one. The program is judged on the fifth.
• Filing the SOC 2 without reading it. An unread report with three exceptions in Section 4 is worse than no report, because you have documented that you looked.
• Tiering by spend. Invoice size correlates poorly with data access and not at all with blast radius.
• One giant questionnaire for everyone. It guarantees low-quality answers from small vendors and irritation from large ones.
• No owner on the row. Unowned rows do not get reviewed, and unreviewed rows are what auditors sample.
• Missing the subprocessors. Your vendor's vendors handle your data too, and ISO 27001 A.5.21 asks about exactly that.

Making the assessment repeatable

The assessment itself is not hard. Keeping fifty of them current is, and that is a scheduling problem rather than a security one. What makes it hold is boring infrastructure: every vendor carrying an owner and a next-review date, every certificate carrying an expiry, and reminders that fire before the date rather than after the auditor asks.

That is the job vendor risk management software does, and in Complies it sits in the same system as your controls and evidence, so a completed vendor review is filed as evidence against SOC 2 CC9.2 and ISO 27001 A.5.19 to A.5.22 rather than as a document in a drive. The risk register holds the risks the assessment surfaces, and evidence collection keeps the underlying artifacts fresh. Prices are published, from $79 a month, with vendor risk included from the $199 Growth plan, and you can connect your stack and see where you stand the same day.

If you are still deciding whether this needs a tool at all, the honest version of that question is in do you need TPRM software. For most companies the answer is not yet, and then abruptly yes, at roughly the point where the vendor list crosses forty and the first expiry slips past unnoticed.