The most important thing CSF 2.0 did for third-party risk is where it put it. In CSF 1.1, supply chain lived under Identify as ID.SC. In CSF 2.0 it was promoted into the new Govern function as GV.SC, "Cybersecurity Supply Chain Risk Management." That is not a renaming exercise. It reframes third-party risk from an identification activity the security team does into a governed program the organisation owns, with strategy, roles, and board-level accountability. Teams that treat GV.SC as a relabelled ID.SC miss the entire point of the move.
CSF is outcome-based: GV.SC tells you what good looks like across ten subcategories and leaves the how to you. That is a feature when you use Profiles to drive it and a liability when you read the subcategories as a checklist. This is how to operationalise GV.SC as a maturity path, not a to-do list.
Scope. For organisations using NIST CSF 2.0 (released February 2024) as their cybersecurity program backbone, and the security and risk leaders who own third-party risk. CSF is voluntary and non-certifiable; where you need auditable depth, GV.SC maps to NIST SP 800-161r1 for C-SCRM and onward to 800-53. Audience: program owners building or maturing a C-SCRM capability.
The ten GV.SC subcategories as a program, not a list
Read top to bottom, GV.SC describes a lifecycle: establish the program, assign the roles, integrate it into risk management, know and prioritise your suppliers, set requirements, do due diligence, understand and monitor the risk, plan for incidents together, integrate over the technology lifecycle, and plan the exit.
| Subcategory | Outcome |
|---|---|
| GV.SC-01 | A C-SCRM strategy, objectives, and policy are established and agreed by stakeholders |
| GV.SC-02 | Roles and responsibilities are set internally and with suppliers |
| GV.SC-03 | C-SCRM is integrated into cybersecurity and enterprise risk management |
| GV.SC-04 | Suppliers are known and prioritized by criticality |
| GV.SC-05 | Requirements to address risk are established and included in contracts |
| GV.SC-06 | Planning and due diligence are performed before entering a relationship |
| GV.SC-07 | Supplier risks are understood, recorded, prioritized, and monitored over the relationship |
| GV.SC-08 | Relevant suppliers are included in incident planning, response, and recovery |
| GV.SC-09 | Supply chain security is integrated across the technology lifecycle |
| GV.SC-10 | C-SCRM plans include provisions for the end of the relationship (offboarding) |
GV.SC-04 and GV.SC-07 are where the register lives: a prioritized supplier inventory, and the recorded, monitored risk against each. The other eight are the governance and lifecycle wrapper that make the inventory mean something.
GV.SC-08 is the subcategory nobody rehearses. Including suppliers in incident response is the outcome most programs claim and fewest test. When a Tier 1 SaaS provider is breached, do you have their incident contact, a contractual notification duty, and a joint runbook, or do you find all three out during the incident? A single tabletop that includes a critical supplier surfaces more gaps than a year of questionnaires.
Build GV.SC-04 first: the prioritized supplier inventory
Everything downstream keys off knowing your suppliers and ranking them by criticality. Build the inventory from procurement and from what is technically in use, then prioritise by the impact of failure or compromise, not by spend.
The inventory record for each prioritized supplier should carry: the service and its criticality ranking (GV.SC-04), the risk assessment result recorded and dated (GV.SC-07), the contractual requirements set (GV.SC-05), due-diligence evidence from onboarding (GV.SC-06), incident-response integration details (GV.SC-08), and the offboarding plan (GV.SC-10). That is the same relational core as every other framework's register, expressed as outcomes.
Use Profiles to make it a maturity path
This is what separates CSF from a checklist. Build a Current Profile (how each GV.SC subcategory operates today) and a Target Profile (where it needs to be, given your risk and any regulatory drivers), and treat the gap as the roadmap. Organizational Tiers (1–4) describe how rigorous and repeatable the governance is, from ad hoc to adaptive. Reporting "we are Tier 2 on GV.SC today, Target Tier 3 by year-end, gaps in GV.SC-07 monitoring and GV.SC-10 offboarding" is a governance conversation a board can act on, which is exactly why supply chain moved into Govern.
Common mistakes
- Treating GV.SC as relabelled ID.SC, keeping it a security-team activity instead of a governed program.
- Reading the ten subcategories as a checklist and skipping the Profile that turns them into a maturity path.
- Prioritising suppliers by spend rather than by impact of compromise (GV.SC-04).
- Recording supplier risk once at onboarding and never monitoring it over the relationship (GV.SC-07).
- Claiming GV.SC-08 without ever running a supplier-inclusive incident exercise.
- No offboarding provisions (GV.SC-10), so terminated suppliers keep access and retain data.
What an assessor or auditor looks for
CSF is voluntary and non-certifiable, so there is no pass/fail audit, but GV.SC is assessed constantly, by internal audit, by a customer's third-party-risk team reviewing you, or through a mapping to 800-53 for a FedRAMP or 800-171 context. In every case the questions are the same:
- Is there a documented C-SCRM strategy and policy (GV.SC-01) with named ownership (GV.SC-02)?
- Is there a prioritized supplier inventory (GV.SC-04), and is the prioritisation defensible?
- Are supplier risks recorded and monitored over time (GV.SC-07), not just captured at onboarding?
- Is there evidence of the lifecycle, due diligence in (GV.SC-06), incident integration (GV.SC-08), offboarding out (GV.SC-10)?
- Do Current and Target Profiles exist, with measured progress? That is the difference between a program and a policy.
Evidence and documentation to keep
- The C-SCRM strategy and policy, with roles (GV.SC-01/-02).
- The prioritized supplier inventory and the prioritisation method (GV.SC-04).
- Recorded supplier risk assessments with dates and monitoring history (GV.SC-07).
- Contract requirement templates (GV.SC-05) and due-diligence records (GV.SC-06).
- Supplier-inclusive incident-response artefacts (GV.SC-08), offboarding checklists (GV.SC-10), and the Current/Target Profiles.
The same discipline across frameworks
GV.SC is the outcome-based, governance-first posture of a discipline every framework shares: know your third parties, prioritise them, set requirements, assess, monitor, and exit. The prioritized inventory you build for GV.SC-04 maps across all five. Mappings are approximate and directional.
| Framework | Control | Posture |
|---|---|---|
| DORA | Art 28(3) + ITS (EU) 2024/2956 | Prescriptive, machine-validated register (financial entities) |
| NIS2 | Art 21(2)(d) | Outcome-based directive; direct suppliers; no format |
| ISO/IEC 27001:2022 | A.5.19–A.5.23 | Certifiable; justified in the Statement of Applicability |
| NIST CSF 2.0 (this article) | GV.SC | Outcome-based; profiles and tiers; maps to 800-161r1 / 800-53 |
| CIS Controls v8.1 | Control 15 | Prescriptive safeguards, IG1→IG3 |
Key takeaways
- GV.SC moved to Govern deliberately, treat third-party risk as a governed program with strategy and roles, not an Identify task.
- Build GV.SC-04 (prioritized inventory) and GV.SC-07 (recorded, monitored risk) first; the other subcategories wrap them.
- Prioritise by impact of compromise, never by spend.
- Use Current and Target Profiles to turn the ten outcomes into a board-legible maturity roadmap.
- Rehearse GV.SC-08 with a real critical supplier; it is the most-claimed, least-tested outcome.
References and further reading
- NIST Cybersecurity Framework 2.0, the Govern function and the GV.SC category.
- NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices, for implementation depth beneath GV.SC.
- NIST CSF 2.0 informative references mapping GV.SC to 800-53 controls where auditable rigor is required.
Frequently Asked Questions
What changed from CSF 1.1 ID.SC to CSF 2.0 GV.SC?
Supply chain risk management moved from the Identify function (ID.SC in 1.1) into the new Govern function as GV.SC in 2.0, and expanded to ten subcategories covering strategy, roles, prioritisation, contracting, due diligence, monitoring, incident integration, lifecycle, and offboarding. The shift reframes third-party risk as a governed organisational program with accountability, not an identification activity owned solely by security.
Can you get certified against NIST CSF 2.0?
No. CSF is a voluntary framework with no certification scheme. You assess yourself using Current and Target Profiles and Organizational Tiers, and where auditable rigor is needed you map GV.SC to NIST SP 800-161r1 and 800-53, which underpin regimes like FedRAMP and 800-171 that do carry formal assessment.
Where does the supplier inventory sit in GV.SC?
GV.SC-04 requires suppliers to be known and prioritized by criticality, and GV.SC-07 requires their risks to be recorded, prioritized, and monitored over the relationship. Together they are the supplier register expressed as outcomes; build both first, since the remaining subcategories govern the inventory's lifecycle.
How do Profiles help with supply chain risk specifically?
A Current Profile captures how each GV.SC subcategory operates today; a Target Profile states where it needs to be. The gap between them is your C-SCRM roadmap, expressed in terms a board can prioritise and fund, which is the practical payoff of supply chain risk sitting in the Govern function.