GV.SC-07 asks that the risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship. In plain terms: a one time questionnaire at signup does not meet it. You need a record per supplier, a tiering decision, and a way to notice when things change.
CSF is voluntary guidance. There is no CSF certification, so the goal is a practice you can describe and show, not a badge.
What good looks like
Every supplier that touches your data, your code or your uptime has a row in a register. Each row has an owner, a criticality tier, the date of the last assessment, open issues and the date of the next review. Critical suppliers get more depth and more frequent checks than a vendor that sells you office chairs.
How to implement it
- List suppliers from your accounts payable export, your SSO app list and your cloud bills. Merge duplicates.
- Tier them. A simple rule works: Tier 1 if an outage or breach would stop revenue or expose customer data, Tier 2 if it would hurt but not stop you, Tier 3 for the rest.
- Match the assessment to the tier. Tier 1 gets a questionnaire, a review of their attestations and contract terms, and an annual check. Tier 3 gets a quick look at their public security page.
- Evaluate evidence against what the contract requires, such as self attestations, warranties, certifications and reports. Read the scope and dates, not only the logo.
- Monitor. Subscribe to the supplier's status and security notices, watch for breach news, and reassess the tier when their role in your business changes.
- Write a short continuity note for each Tier 1 supplier: what you do if they disappear for a week.
A worked example
Take a small software company with forty suppliers. After tiering, six land in Tier 1: the cloud host, the payment processor, the identity provider, the code hosting service, the customer support platform and the email delivery service. Each gets a half day of attention in the first year. The security lead reads the supplier's latest attestation report and notes the scope and dates, checks the contract for breach notice terms, confirms that the supplier's status page and security contact are subscribed, and writes two lines on what happens if the service is unavailable for three days.
Eleven Tier 2 suppliers get a shorter questionnaire and a check of their public trust page. The remaining twenty three get a one line entry and a look when the contract renews. The whole first pass takes a few weeks of part time work, and from then on the effort is mostly watching for change.
Triggers worth writing down
Calendar reviews are the floor. Add event triggers so the register reacts to the world:
- A security incident or breach notice from the supplier.
- A change of ownership or a major change in the supplier's infrastructure.
- A new use case, such as sending a new data type to an existing vendor.
- A lapsed or changed attestation report.
- An outage that exceeded your tolerance.
Each trigger should lead to a short reassessment, a recorded decision and, where needed, a change in tier. That is what separates ongoing monitoring from a stack of old questionnaires.
Responding to what you find
The outcome includes responded to, which people forget. When an assessment turns up a gap, record the response: accept the risk with an owner and date, ask the supplier to fix it by a deadline, add a compensating control on your side such as encryption before upload, or plan to exit. A register of findings with no responses shows that the work stopped halfway.
Evidence to collect
- The supplier register with tier, owner and review dates.
- Completed assessments and the reviewer's notes on gaps.
- Contract clauses that set security obligations.
- A log of supplier incidents or changes and what you did about them.
- Continuity notes for critical suppliers.
Common gaps
- The register exists but nobody updates it after onboarding.
- Every supplier gets the same long questionnaire, so the important ones get shallow attention.
- Certificates are collected but nobody checks scope or expiry.
- No trigger to reassess when a supplier is acquired or has an incident.
Try it yourself
The demo below walks through a vendor risk review from intake to a decision.
Click through it at your own pace, or open it full screen.
Quick check
How often should you review a critical supplier?
At least annually, and also whenever something changes: an incident, an acquisition, a new service, or a change in how much you depend on them. The outcome says over the course of the relationship, so the review is triggered by events as well as the calendar.
Does a supplier's certificate close the question?
No. It is one piece of evidence. Check what it covers, the period, and whether the services you actually use are in scope.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
