GV.SC-04: Suppliers are known and prioritized by criticality

GV.SC-04 sits in the NIST Cybersecurity Framework (CSF) 2.0 Governance function under Supply Chain (SC). The requirement is short, but examiners expect a real operating model behind it: you know who your suppliers are, you know which ones matter most, and you can prove you run risk processes differently for a critical supplier than for a low-impact one. The control fails most often for mundane reasons: decentralized procurement, “shadow” SaaS, incomplete contract metadata, and criticality ratings that exist in a spreadsheet but don’t change anyone’s behavior.

Operationalizing GV.SC-04 is a linking exercise. Your supplier inventory must connect to what the supplier supports (business service), what the supplier touches (systems), and what the supplier can access (data and privileges). Then your criticality method must translate that linkage into a prioritization that drives action: onboarding gates, security reviews, contractual protections, ongoing monitoring, and contingency planning.

This page gives requirement-level guidance you can implement quickly: who owns what, what to build, what evidence to retain, and what auditors commonly challenge. Source references: NIST CSF 2.0 and NIST’s CSF 1.1 to 2.0 transition mapping (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Regulatory text

Requirement (verbatim): “Suppliers are known and prioritized by criticality.” (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes)

What the operator must do:
You must (1) identify your suppliers (third parties that provide products or services) and (2) prioritize them by criticality using defined criteria. “Known” means you can produce a complete inventory, not a partial list from Procurement. “Prioritized” means you assign a tier or rank that is approved, maintained, and used to drive downstream controls (due diligence depth, contract requirements, monitoring, and resilience planning). (NIST CSWP 29)

Plain-English interpretation

• Build one authoritative supplier inventory (a system of record) that includes enough context to assess impact.
• Decide what “critical” means for your organization, then score/tier every supplier.
• Make the tiering operational: the tier must change the workflow (what reviews happen, who approves, what clauses are required, and what monitoring is performed).
• Revisit the inventory and tiers when suppliers, services, or access change, and on a recurring schedule you can demonstrate.

Who it applies to (entity and operational context)

Applies to: Any organization running a cybersecurity program with external dependencies, including regulated and non-regulated entities, because critical suppliers can create material operational, security, privacy, and resilience risk. (NIST CSWP 29)

Operational contexts where GV.SC-04 is tested hard:

• Heavy SaaS footprint (identity, CRM, HRIS, finance, support desk).
• Managed service providers (MSPs/MSSPs), cloud hosting, data analytics platforms.
• Payment processors, claims processors, call centers, fulfillment partners.
• Software supply chain dependencies (libraries, outsourced development, code signing, CI/CD providers).

Third parties in scope (use broad coverage): Vendors, contractors, consultants, processors, sub-processors, outsourcing partners, and affiliates providing services that support your business services or touch your systems/data.

What you actually need to do (step-by-step)

Step 1: Name the control owner and define governance

1. Assign ownership for the supplier inventory and tiering method (often TPRM, InfoSec GRC, or Procurement with Security oversight).
2. Set RACI for: intake/onboarding, inventory maintenance, tier approval, exception handling, and periodic review.
3. Document the procedure in a Third-Party Risk Management (TPRM) standard or supply chain risk procedure mapped to GV.SC-04. (NIST CSWP 29)

Operator tip: If Procurement owns the tool, Security still needs documented authority to define criticality criteria and to stop onboarding for missing data.

Step 2: Build an authoritative supplier inventory (the “known suppliers” part)

Minimum fields that make criticality defensible:

Field	Why it matters in audits
Legal entity name + DBA	Prevents duplicates and “unknown” affiliates
Service provided / product	Connects supplier to business purpose
Business owner	Accountable internal stakeholder
System(s) integrated	Shows technical dependency
Data types accessed/processed/stored	Links to confidentiality/privacy impact
Access method (API, SSO, VPN, agent)	Drives security control requirements
Privilege level	Drives inherent risk and monitoring depth
Subcontractors (if known)	Exposes fourth-party concentration risk
Contract start/end + renewal	Enables reassessment triggers
Geographic/service delivery footprint	Affects operational and regulatory exposure
Incident contacts + escalation path	Enables response readiness

How to get completeness fast:

• Pull supplier candidates from AP/finance, procurement, contract repository, SSO/SAML app catalog, CASB (if you have it), and cloud marketplace billing.
• Normalize names and merge duplicates.
• Require business owners to attest their lists are complete for their cost centers.

Step 3: Define “criticality” with criteria you can defend

Create a criticality standard that is simple enough to apply consistently. Use criteria like:

• Business service impact: Would failure materially disrupt a core business service?
• Recovery constraints: Can you run manually, or do you have a viable alternative?
• Data sensitivity and volume: Does the supplier handle regulated, confidential, or high-impact data?
• Access and integration depth: Does the supplier have network access, admin access, or persistent agents?
• Operational concentration: Is the supplier a single point of failure (only provider, hard to replace)?
• Security externalities: Would compromise create downstream compromise risk (shared credentials, code pipeline, identity controls)?

Define tiers (example):

• Tier 1 (Critical): Outage or compromise plausibly causes material service disruption or high-impact data exposure.
• Tier 2 (High): Significant impact but with workable compensating options.
• Tier 3 (Standard/Low): Limited impact, low access, easy to replace.

Write these definitions in a one-page standard and get approval from the risk committee, CISO, or equivalent governance body. (NIST CSWP 29)

Step 4: Score/tier every supplier, then validate with stakeholders

1. Assign an initial tier via questionnaire or internal assessment using your criteria.
2. Review outliers (e.g., “low” tier but has production admin access).
3. Obtain business owner sign-off and InfoSec approval for Tier 1 suppliers.
4. Record rationale in the inventory (short narrative: “Supports customer authentication; outage blocks logins; processes customer identifiers; integrates via SSO + SCIM”).

Step 5: Make criticality drive downstream controls (where most programs break)

Define mandatory actions per tier. Keep it table-driven so it’s auditable.

Control area	Tier 1 (Critical)	Tier 2 (High)	Tier 3 (Standard/Low)
Pre-contract security review	Full assessment + remediation plan	Standard assessment	Lightweight screening
Contract/security addendum	Required baseline + right-to-audit + incident notice	Baseline clauses	Minimal clauses
Ongoing monitoring	Continuous/periodic monitoring and re-attestation	Periodic review	Event-driven review
Access controls	Strong auth, least privilege, logging requirements	Standard access guardrails	Basic controls
Resilience	Documented exit/transition plan	Document alternatives	No formal exit plan required
Incident readiness	Tested contacts/escalation	Defined contacts	Basic contacts

You are not required to pick any specific assessment standard in GV.SC-04, but your tiering must clearly influence what you do next. Tie this to your existing framework mappings (SOC 2, ISO 27001, internal risk policy) to reduce duplicate work. (NIST CSWP 29)

Step 6: Set triggers and a review cadence you can evidence

Define events that force re-tiering:

• Material scope change (new data type, new integration, privilege change).
• New sub-processor usage that changes concentration risk.
• Major incident, repeated SLA failures, or significant control degradation.
• Contract renewal or renegotiation.

Also run a periodic review (documented, owned, and evidenced). GV.SC-04 does not prescribe timing; pick an interval you can sustain and defend based on risk.

Step 7: Operationalize reporting

Minimum reporting views:

• List of Tier 1 suppliers, with owners, services supported, renewal dates.
• Suppliers missing a tier (should be zero).
• Tier changes over time (audit trail).
• Exceptions: who approved and why.

Where Daydream fits naturally: If you struggle with inventory completeness, evidence collection, and producing auditor-ready exports, Daydream can act as a control hub: mapping GV.SC-04 to the owner, procedure, and recurring evidence requests so your tiering doesn’t live in someone’s spreadsheet.

Required evidence and artifacts to retain

Auditors usually accept “reasonable evidence” if it is consistent, complete, and time-bound. Retain:

• Supplier inventory export (dated) showing required fields and criticality tier.
• Criticality methodology document (criteria, tier definitions, approval).
• RACI / ownership documentation.
• Completed tiering assessments (or scoring worksheets) with rationale for Tier 1 suppliers.
• Approval evidence (ticket, workflow approval, meeting minutes) for Tier 1 list.
• Procedure for onboarding and inventory maintenance (including triggers).
• Samples of downstream actions driven by tier:
  • Tier 1 due diligence package
  • Contract/security addendum
  • Monitoring records
  • Exit/transition plan (where required by your tiering policy)

Common exam/audit questions and hangups

1. “How do you know the inventory is complete?” Expect to show source reconciliation (AP vs SSO vs procurement) and ownership attestations.
2. “Define ‘critical.’ Who approved it?” They want criteria and governance, not ad hoc labels.
3. “Show me that criticality changes your process.” Bring side-by-side examples: Tier 1 contract vs Tier 3 contract; Tier 1 assessment depth vs Tier 3.
4. “How do you handle shadow SaaS?” Demonstrate discovery inputs and an intake gate.
5. “How do you manage fourth parties?” Even if you can’t inventory all sub-suppliers, show how you request sub-processor lists for higher tiers and track known dependencies.

Frequent implementation mistakes and how to avoid them

• Mistake: Inventory equals “top 50 vendors by spend.” Fix: reconcile across finance, identity, and IT application inventories.
• Mistake: Criticality = inherent risk score from a questionnaire only. Fix: include business service impact and replaceability, not just security posture.
• Mistake: Tiering exists but does not drive actions. Fix: publish a tier-to-control matrix and make workflows enforce it.
• Mistake: No owner for updating supplier records. Fix: assign a record steward and require updates through a ticketing workflow.
• Mistake: Tier 1 list is politically negotiated. Fix: tie criteria to business service mapping and document rationale; require risk acceptance for exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions or penalties.

Practically, GV.SC-04 reduces two types of failure that regulators and customers care about: (1) a major incident at a supplier you failed to treat as critical, and (2) an inability to evidence basic governance (who your suppliers are, which ones matter, and what you did about it). In cyber incidents, organizations often discover unknown suppliers through logs and invoices; GV.SC-04 is designed to prevent that operational surprise. (NIST CSWP 29)

Practical 30/60/90-day execution plan

First 30 days: get to an inventory you can defend

• Appoint owner and publish RACI for supplier inventory and tiering.
• Stand up the supplier inventory schema (fields table above) in your chosen system (GRC tool, vendor management platform, or controlled spreadsheet with workflow).
• Pull initial supplier lists from AP, procurement, SSO/app catalog, and IT.
• Draft criticality criteria and tier definitions; route for approval.

Days 31–60: tier everything and fix the top risks

• Complete tiering for all suppliers; require business owner sign-off for Tier 1 candidates.
• Validate Tier 1 list with cross-functional review (Security, Procurement, Legal, business).
• Build the tier-to-control matrix and implement onboarding gates (no tier, no contract signature for in-scope suppliers).
• Identify Tier 1 suppliers missing baseline artifacts (security addendum, incident contacts, assessment) and open remediation tickets.

Days 61–90: make it repeatable and auditable

• Implement trigger-based updates (renewals, scope changes, new integrations).
• Create recurring evidence collection and reporting: Tier 1 dashboard, exceptions log, tier change audit trail.
• Run a tabletop exercise that includes at least one Tier 1 supplier failure scenario and confirm contacts and escalation paths.
• Package an “audit binder” sample: inventory export, methodology, approvals, and two Tier 1 supplier files showing downstream controls.

Frequently Asked Questions

Does “supplier” mean only vendors with contracts?

Treat “supplier” broadly as third parties your operations depend on, including SaaS tools, contractors, and processors. If a third party can affect a business service or access systems/data, include it in scope under your GV.SC-04 operating definition. (NIST CSWP 29)

How detailed does the criticality methodology need to be?

Keep it short but specific: tier definitions, criteria, who approves tiers, and triggers for re-tiering. Auditors care more about consistency and evidence than about complex scoring math. (NIST CSWP 29)

We have multiple inventories (Procurement, IT, Finance). Which one is “authoritative”?

Pick one system of record for GV.SC-04 and document how other sources reconcile into it. Keep the reconciliation evidence so you can answer completeness challenges during audits.

What if business owners disagree with a Tier 1 label?

Require a documented exception or risk acceptance with sign-off at a defined level. Preserve the rationale and the approver; auditors will test whether criticality is objective or negotiable.

How do we handle suppliers that don’t touch data but are operationally essential?

Criticality is not only about data. If the supplier is a single point of failure for a core business service, it can be Tier 1 even with minimal data exposure; document the service dependency and recovery constraints.

What evidence is “enough” to prove tiering drives action?

Show two or three examples where Tier 1 suppliers went through deeper due diligence, had stronger contract language, and receive more active monitoring than low-tier suppliers. The contrast is persuasive in exams.