Vendors
Vendors, or "Entities" represent the external organizations your program depends on: suppliers / vendors, subprocessors, and service providers. An entity record holds the relationship in one place, with the risk classification, review schedule, contract terms, security posture, and supporting documents that due diligence requests and audits draw on.
Vendor management programs generally tier vendors by potential impact and let the tier drive the depth and cadence of review: a critical data processor warrants an annual questionnaire, System and Organization Controls 2 (SOC 2) report review, and contract scrutiny, while a low-impact tool gets a lightweight check at renewal. We built tiering and review scheduling into the entity record so assessments recur instead of happening once at onboarding.
How Entities Work
Each entity record carries a lifecycle status so terminated vendors stay auditable for the covered period instead of disappearing when the relationship ends, and teams evaluating a new vendor can see where it stands before due diligence completes.
Two settings turn the record into a management tool: the vendor tier classifies how much scrutiny a relationship warrants, and the review frequency plus next review date turn that classification into a schedule. The record also holds the contract terms and security posture details you gather during reviews, and an approved-for-use flag gives teams a simple yes or no to check before adopting a vendor.
Entities tie together the contacts you correspond with at the vendor, the documents collected during reviews, and the subprocessors you disclose publicly. For the complete field list, see the GraphQL object reference.
Working with Entities
Build and Tier the Vendor Inventory
Import your vendor list via CSV, then assign each entity a tier based on the data it touches and the blast radius if it fails. A useful heuristic: anything processing customer or regulated data, or sitting in the production path, is Critical or High; internal tooling with no sensitive data is Standard or Low. Assign an internal owner to each entity so every vendor has a person accountable for its reviews.
Run Due Diligence on a Cadence
Set a review frequency and next review date on each entity, scaled to its tier. When a review comes due, send a vendor assessment campaign to the vendor's contact, attach the returned SOC 2 report and questionnaire responses to the entity, and record who reviewed it and when. The entity becomes the audit trail: an auditor asking "show me your last review of this vendor" gets a record with a reviewer, a date, and the supporting documents rather than a search through shared drives.
Track Contracts and Renewals
Record contract end dates, renewal dates, auto-renewal terms, and termination notice periods on each entity, then schedule reviews ahead of renewals so findings can actually influence the decision. A questionnaire completed before the termination notice window closes can still change the renewal decision; one completed after auto-renewal fires cannot.
Feed the Trust Center
If you publish a trust center, your public subprocessor list can be built from entities you already manage: the subprocessor page lets you add subprocessors from your existing vendor list. Keeping vendor records current in the registry then keeps your public disclosures current too, instead of maintaining the same list twice.
FAQ
What is the difference between tier and risk rating?
Tier is your classification of how much the relationship matters: how much scrutiny it warrants, driven by the data and access involved. Risk rating and risk score capture what assessments actually found. They move independently. A critical-tier vendor can carry a low risk rating after a clean review, and that combination is exactly what you want: high scrutiny confirming low risk.
What status should a vendor have while we evaluate it?
Start the record in Draft when someone proposes the vendor, move it to Under review while due diligence runs, then to Approved or Rejected based on the outcome. Keep approvedForUse false until the review completes so teams checking whether they can adopt the vendor get an accurate answer during the evaluation window.
How should we handle a vendor we stop using?
Move the entity through Offboarding while you confirm data return or deletion and access removal, then set it to Terminated and clear approvedForUse. Keep the record: audits cover the full period, and a vendor terminated mid-period still needs its review history available.
Examples
- CSV
- GraphQL
- Go Client
- CLI
# Create
Name,DisplayName,Status,RiskRating,ReviewFrequency,NextReviewAt,ApprovedForUse,HasSoc2
stripe,Stripe,active,HIGH,YEARLY,2026-10-01T00:00:00Z,true,true
aws,Amazon Web Services,active,MEDIUM,YEARLY,2026-09-15T00:00:00Z,true,true
# Update
ID,RiskRating,NextReviewAt,ContractRenewalAt,ApprovedForUse
ENT01J9ABCD111111111111111,MEDIUM,2026-11-01T00:00:00Z,2027-01-31T00:00:00Z,true
ENT01J9ABCD222222222222222,HIGH,2026-08-01T00:00:00Z,2026-12-31T00:00:00Z,true
mutation {
createEntity(
input: {
name: "stripe"
displayName: "Stripe"
status: "active"
description: "Payment processor"
}
) {
entity {
id
displayName
}
}
}
mutation {
updateEntity(
id: "ENT01J9ABCD111111111111111"
input: {
status: "active"
description: "Annual vendor review completed"
}
) {
entity {
id
status
}
}
}
ctx := context.Background()
name := "stripe"
displayName := "Stripe"
status := "active"
_, err := client.CreateEntity(ctx, graphclient.CreateEntityInput{
Name: &name,
DisplayName: &displayName,
Status: &status,
})
if err != nil {
return err
}
description := "Annual vendor review completed"
_, err = client.UpdateEntity(ctx, "ENT01J9ABCD111111111111111", graphclient.UpdateEntityInput{
Description: &description,
})
if err != nil {
return err
}
openlane entity create \
--name "stripe" \
--display-name "Stripe" \
--status "active"
openlane entity update \
--id "ENT01J9ABCD111111111111111" \
--status "active" \
--description "Annual vendor review completed"