Vendor reviews

Run a periodic review campaign over your vendors, approve each one or reject it with a finding, and finish with a report that records who decided what.

An assessment looks at one vendor; a review looks at the register. A vendor review is a campaign with a coordinator and a deadline. In it, every vendor in scope is approved or rejected in turn. ISO 27001 and your own supplier policy ask for this periodic check. The record the review leaves is the evidence that the check took place.

A review saves a snapshot of each vendor when it starts. The reviewer judges the vendor as it was at the start of the campaign. The finished review stays correct after the vendors change. Risk and asset reviews work the same way.

Run a review

Open Vendors → Reviews and choose Start Vendor Review.
Give it a Title, a Coordinator (a business role, who is notified) and a Deadline, and choose the Priority that decides which vendors are in scope. Notes are free text.
Open the review. Each vendor in scope is an item with its snapshot: the ratings, the owner, the fields of the vendor record. Compare with shows the snapshot against the vendor's latest version or against the same vendor in another review, inline or as a split view.

Compare with shows what changed since the review started. Here it is one note on a control.
Approve the vendors that still look acceptable. Reject the ones that do not. The dialog asks for a Finding type (major nonconformity, minor nonconformity, observation or opportunity for improvement) and a Reason. It then raises a finding in the findings register. While the review is open, Withdraw takes a decision back. Withdrawing a rejection archives its finding with a note.
Finish Review when every vendor is decided. A finished review is locked; its items can no longer be changed and it cannot be reopened.
Generate Report produces the Vendor Review Report for the campaign.

Datadog is rejected as an observation. The rejection becomes finding OBS-007 in the findings register.

Findings raised in earlier reviews that are still open are listed at the top of the next review, so a rejection is not forgotten between campaigns.

Which vendors are in scope

The Priority chosen at the start fixes the scope; it cannot be changed afterwards. Archived vendors are never in scope; inactive and offboarded ones are, unless you archive them.

Priority	Vendors in the review
All Vendors	Every vendor.
High Risk Only, Medium Risk Only, Low Risk Only	Rated vendors whose higher rating (inherent or residual, whichever sits in the higher level) falls in that tier. Unrated vendors are left out.
Due for Reassessment	Vendors whose latest assessment is overdue, or whose next review falls within the next 14 days.

The tiers come from your risk settings: a level outside the appetite is high, the lowest level is low, and the rest are medium.

Reviews and the overview

The overview's Review due finding and its Reviewed within the interval bar both read the reviews. A vendor counts as reviewed when it was approved in a review within the Review interval of your risk settings. A vendor created more recently than the interval is not flagged yet.

Reference

Review fields

Field	Values and notes
Title	Required.
Coordinator	Required. A business role.
Priority	All Vendors, High Risk Only, Medium Risk Only, Low Risk Only, Due for Reassessment. Fixed once the review exists.
Deadline	A date.
Notes	Free text.
Finished at	Set by Finish Review.

A review has the ID form VAR-001. Its list shows the coordinator, the deadline, when it started and ended, and how many items are approved and how many remain; it filters by Coordinator, Deadline, Review started and Review ended. A review can be archived and restored from the row menu (restoring is refused at the plan ceiling), and deleted.

Permissions

Owners and admins start, decide and finish reviews; members and auditors read them.

API

Method and path	Does
`GET /vendor-reviews/`	List reviews.
`POST /vendor-reviews/`	Start a review; the items are created from the priority.
`GET /vendor-review/{id}/`	One review. The singular `vendor-review` in this path and in `DELETE` is how the API names them; it is not a typo.
`PATCH /vendor-reviews/{id}/`	Update notes or deadline (`title` and `coordinatorId` are required in the body), or set `finishedAt` to finish; finishing needs every item decided and cannot be undone.
`DELETE /vendor-review/{id}/`	Delete a review.
`POST /vendor-reviews/{id}/archive/`, `POST /vendor-reviews/{id}/restore/`	Archive and restore.
`PATCH /vendor-review-items/{id}/`	Approve an item (`approved: true`) or set it back to pending (`false` or `null`); either withdraws a rejection and archives its finding.
`POST /vendor-review-items/{id}/reject/`	Reject an item with a `reason` and a `findingType` (`MAJOR_NONCONFORMITY`, `MINOR_NONCONFORMITY`, `OBSERVATION`, `OPPORTUNITY_FOR_IMPROVEMENT`), and raise the finding. Refused on a finished review or an item already rejected.

The full description of each call is in the API reference.

How is this guide?