GV.SC-05 Supplier security requirements in contracts

What GV.SC-05 asks for in supplier contracts

If you review supplier contracts, GV.SC-05 expects your organization to set cybersecurity requirements for suppliers, prioritize them, and write them into contracts and other agreements. This Subcategory sits in the Cybersecurity Supply Chain Risk Management (GV.SC) Category under the GOVERN Function of CSF 2.0. It carries forward CSF 1.1 ID.SC-3 under a new identifier, so a contract clause you mapped to the older number still belongs here. The risk it addresses is simple: if the agreement says nothing about security, you have no enforceable way to receive vulnerability notices, a software or hardware bill of materials (SBOM), or evidence that a supplier's controls work. Asking for these things after signature usually means relying on goodwill.

The work is hard for three reasons. Contracts are owned by procurement and legal, who may not know which clauses matter for security. Requirements should differ by criticality, so a low-risk tool does not need the same terms as a provider holding regulated data or privileged access, and that depends on the supplier inventory and ranking from GV.SC-04. Finally, a clause only has value if someone checks it later. Ask your legal and procurement teams for a default security schedule with tiered requirements, a rule for which tier each supplier falls into, and named owners for SLA reporting, vulnerability disclosure and evidence requests. Confirm with counsel which terms your jurisdiction and sector allow you to enforce.

Before renewing or signing, check four things: whether the agreement sets security SLAs with defined response expectations, whether it requires the supplier to disclose vulnerabilities in its products, whether it requires a current SBOM or hardware bill of materials for critical products, and whether it names the attestations or certifications you will accept as evidence. Using a tool such as Dependency-Track can help you act on SBOMs once received, but the right to receive them must be in the contract first. The NIST CSF 2.0 Reference Tool lists the Implementation Examples and mappings for GV.SC-05 if you want to compare your clauses against them.

Which contracts and suppliers fall under GV.SC-05

GV.SC-05 does not apply the same contract clauses to every supplier. The scope of the work depends on how each supplier is ranked, what data it touches, how it reaches your systems and whether it supplies critical products or manages services for you. The cards below describe the scoping decisions that change the contract workload most.

Supplier criticality ranking

The criticality ranking from GV.SC-04 decides which clause set a supplier receives. Suppliers ranked as critical usually need the full package: security requirements in service level agreements, vulnerability disclosure terms and bill of materials obligations. Lower-ranked suppliers may only need default language. Confirm that each criticality tier in your contract templates maps to a documented ranking, and that the ranking is reviewed when a supplier's role changes.

Data handled by the supplier

A supplier that stores, processes or transmits your sensitive data needs contract terms on data protection, incident notification and return or deletion of data at exit. A supplier that handles no regulated or confidential data may need far fewer terms. Ask each business owner which data categories the supplier will see, and record the answer in the supplier file so the contract matches the actual exposure.

Access to your systems

Suppliers with remote administrative access, service accounts or integration credentials into your environment carry a different risk from suppliers that only deliver files or invoices. Access-heavy suppliers usually require clauses on named personnel, multifactor authentication, session logging, background checks for staff with access and prompt revocation. Confirm who holds credentials today, not only who the contract names.

Critical software or hardware

When a supplier provides software or hardware that supports critical functions, GV.SC-05 expects contract terms requiring a current software or hardware bill of materials for those products. Add clauses on vulnerability disclosure and timely notice of issues affecting components. Ask the supplier which format it will provide, how often it will update the inventory, and how it will show that components are sourced from authentic channels.

Managed service providers and cloud providers

Managed service providers and cloud platforms often operate parts of your environment on your behalf, and they may sub-contract their own suppliers. Contracts with these third parties should state which security responsibilities sit with the provider, which sit with you and how the division is documented. Check whether the provider's own subcontractors fall under the same security requirements, and whether you can obtain their assurance evidence.

Suppliers with fourth-party exposure

A supplier that relies on other organizations to deliver its service extends your supply chain. Contracts should require suppliers to flow relevant security requirements down to material subcontractors and to disclose them when they change. Ask each supplier for a list of subcontractors that affect your data or systems, and decide in advance how you will respond if a subcontractor fails to meet the terms.

How an assessor tests supplier security requirements in contracts

This table shows what an assessor samples, what evidence they request and where GV.SC-05 programs usually fall short. It tests the organization's own contracting control, not the supplier's product, and NIST does not certify the result, so only an independent auditor issues an opinion.

Test area	What the assessor checks	Common findings
Supplier register and criticality ranking	Whether the register lists suppliers and ranks them by criticality, so requirements can be set by tier	Criticality is recorded but not used to select which contract clauses apply
Sample of contracts for critical suppliers	Contract files for a sample of critical suppliers, checking that security terms exist and were signed before access was granted	Templates contain security terms, but older or renewed contracts were never updated
Clauses on security requirements	Whether contracts set cybersecurity requirements that match the supplier's risk tier and data or system access	Generic wording with no measurable obligation, owner or review date
Service level terms	Whether security SLAs, such as response times for security issues, are written and tied to a named owner	SLAs cover uptime only, with no security metrics or reporting cadence
Vulnerability disclosure clauses	Whether suppliers must report vulnerabilities in their products or services to the organization within a defined process	Clause exists but no contact point, timeline or escalation path is named
SBOM delivery terms	Whether critical products must come with a current software or hardware bill of materials, and whether receipt is recorded	SBOM requested at purchase but never refreshed after updates, or stored without review
Evidence of security practices	Whether attestations or certifications are requested, dated and reviewed on a set cycle, as the organization defined	Certificates on file are expired or cover a different product or site
Contract terms applied in practice	Whether the organization can show that required evidence was received, reviewed and acted on after signing	Requirements exist on paper, but no records show follow-up, exceptions or remediation

How to write and enforce supplier security requirements step by step

This sequence turns GV.SC-05 from a principle into contract language that matches each supplier's criticality, with clear evidence and monitoring obligations attached. Each step produces a reusable artifact that procurement, legal and security can check against.

Confirm criticality tiers from GV.SC-04
Start from the supplier register maintained under GV.SC-04, where each supplier is ranked by the data it handles, its access to systems and how important its products or services are. Confirm the tier definitions with security, procurement and the business owners, and check that every active supplier has a tier. The output is a tier model with written criteria and a tagged supplier list that the contract team can use without re-interpreting the ranking. The step is done when each tier has a named owner and no supplier is left untiered.
Draft a tiered security schedule
Build a default security schedule with a clause library organized by tier, so higher-criticality suppliers receive stricter requirements such as access controls, data handling, incident notification and verification rights. Legal and security should draft the clauses together, and the verification terms should be written into the default contract language rather than negotiated from scratch each time. The output is an approved template and a clause library, reviewed by counsel. The step closes when the template is approved for each tier.
Define security SLAs for events and remediation
Set service-level terms for security events and vulnerability remediation, scaled to each tier. Ask the business and security teams to agree on what counts as a security event, how quickly the supplier must notify you, and how fast it must fix issues by severity. Confirm the exact timeframes with your incident response and risk owners, since this page does not supply benchmark figures. The output is an SLA annex per tier with measurable metrics and named reporting contacts. The step is complete when each metric has a definition, a measurement source and a remedy for missed targets.
Add vulnerability disclosure and SBOM terms
For critical products, add clauses requiring the supplier to run a vulnerability disclosure process and to deliver a current software or hardware bill of materials. Specify the format you accept, how often updates arrive and how the supplier notifies you of newly disclosed vulnerabilities affecting listed components. Tools such as OWASP Dependency-Track can ingest CycloneDX SBOMs and VEX, so the clause should name a format your intake process can read. The output is an SBOM and disclosure annex with a sample delivery file. The step is done when the security team confirms it can ingest a test delivery.
Set evidence obligations and verification rights
Specify which evidence each tier must provide, such as attestations, certifications or independent reports, and how often it must be refreshed. Include the right to request additional evidence or assessments when a risk signal appears, and require the supplier to notify you of material changes to its security posture. Record which evidence you will accept as equivalent so reviewers do not argue about it later. The output is an evidence schedule mapped to each tier. The step is complete when the schedule is approved and linked to the supplier record.
Execute procurement and legal review
Route each negotiated contract through procurement and legal, checking that the approved schedule, SLAs and evidence terms are present and any deviations are documented with a risk acceptance from the owner. Record each executed agreement in a contract-to-supplier register that links the contract, the tier and the clauses in force. The output is a signed contract with a register entry and an exception log. The step closes when every new or renewed supplier in scope has a register entry.
Align contract terms with the GV.SC-07 monitoring cycle
Connect the register to the monitoring schedule used under GV.SC-07, so assessment frequency, attestation reviews and SLA reporting follow the tier and the dates in the contract. Assign an owner to each supplier for reviews, and set triggers for re-assessment, such as a reported incident or a missed remediation target. Ask the monitoring team to confirm how it will consume the evidence and SBOM feeds. The output is a monitoring calendar linked to the register. The step is complete when each contract has a scheduled review and a named escalation path.

Evidence that satisfies GV.SC-05 and how to keep it current

GV.SC-05 is shown by documents and records, not by intent. The artifacts below connect the contract terms to what an assessor can sample, and each one needs a named owner and a refresh routine between audits.

Tiered clause library with version history

A standard set of supplier security clauses, grouped by criticality tier, with each clause's approval record and revision history. It shows that requirements are set by criticality before any contract is negotiated. Check that every clause traces to a tier, that legal has approved the current version, and that superseded versions remain on file. Procurement or legal owns the library, and security reviews it whenever the tiers change.

Signed contracts and amendments

Executed agreements for critical suppliers, plus every amendment that adds or changes security terms. An assessor will sample these to confirm that the requirements in the clause library actually appear in the signed text. Keep a register that maps each critical supplier to its current agreement and amendment dates, and review it at each renewal. Legal owns the register, and the supplier relationship owner confirms that it matches the file.

SBOMs received for critical products

Software or hardware bills of materials that suppliers deliver for critical products, typically in a machine-readable format such as CycloneDX or SPDX. Ingest them into a tracking tool so they can be compared against known vulnerabilities. Confirm that each SBOM is current for the product version in use and that the contract sets a delivery cadence. Product security or the engineering team that consumes the product owns the refresh, and the supplier owns the accuracy of the content.

SLA reports and breach notices

Periodic reports showing the supplier's performance against the security service levels in the contract, along with any notices of breach and the remediation that followed. These records show that the SLAs are measured and enforced, not only written. Confirm that reporting dates match the contract, that breaches have a documented decision (waive, remediate or terminate), and that the file is retained for the contract term. The relationship owner produces the reports review, and the risk function signs off on breaches.

Vulnerability disclosure terms and contact record

The contract clause requiring the supplier to disclose vulnerabilities, together with a current record of the named security contacts and the channel for reporting. An assessor will check that the contact is still valid and that the terms match what the supplier's own published policy states. Review the contact record at least at each contract anniversary and after any staff change at the supplier. Procurement holds the clause, and the product security team maintains the contact record.

Supplier attestations and certifications on file

Independent reports, certificates and self-attestations that the supplier provides as evidence of its security practices. Record the scope, the issuing body, the validity period and the date the file was last checked. Treat a certificate whose scope does not cover the service you buy as a gap, not as evidence. Confirm the document with the issuer when the source is unclear. Third-party risk staff own the file, and the contract owner requests renewals before expiry.

Insider threat vetting terms

Contract language that requires the supplier to screen personnel with access to your systems or data, along with the supplier's written confirmation of how screening is performed. This evidence covers the insider threat element of GV.SC-05 that many contracts omit. Check that the terms name the roles in scope and that the supplier's confirmation is dated. Procurement and HR-facing security staff own the clause, and the supplier confirms the screening each renewal cycle.

What meeting GV.SC-05 costs in money and effort

This table lists each cost component of writing GV.SC-05 requirements into supplier contracts, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for asking a partner or internal team for a quote, since no price is given here.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Legal drafting of the clause library	One-time, with periodic revision	Number of supplier tiers, number of distinct clause variants, and how many jurisdictions and governing laws apply	Draft one default clause set by criticality tier and use short annexes for product-specific terms
Procurement and legal time per renewal	Recurring, at each contract renewal or amendment	Count of critical suppliers, contract length, and how often suppliers push back on security terms	Pre-approve fallback positions with procurement, and track renewal dates in one register
Security engineering time to define SLAs and SBOM handling	One-time to define, recurring to maintain	Number of critical products, complexity of the SLA metrics, and whether SBOM formats and delivery channels are standardized	Agree on a single SBOM format and delivery method, and limit SLA metrics to those the organization can measure
Tooling or licenses for SBOM and vulnerability tracking	Recurring where commercial licenses apply	Commercial versus open-source tooling, number of components tracked, and hosting model	Self-hosted open-source options such as OWASP Dependency-Track (Apache-2.0) and Trivy (Apache-2.0) can remove license spend, though hosting and staffing remain
Evidence upkeep	Recurring	Frequency of supplier attestations and certifications, number of SBOM refreshes, and how many suppliers return evidence in inconsistent formats	Set one evidence calendar keyed to supplier criticality and store responses in a single system of record
External review of templates	One-time, with periodic refresh	Whether counsel with contract security experience reviews the templates, and how often the clause library changes	Review templates on a fixed cycle and when regulations or contracting practices change, not for every deal
Auditor sampling effort	Recurring, at each assessment cycle	Number of sampled contracts, completeness of clause records, and whether requirements are traceable to the criticality tier	Keep a clause-to-supplier traceability record so samples can be pulled quickly from a single source

Open-source tools that produce SBOM and vulnerability evidence

Contract clauses for software bills of materials and vulnerability disclosure only help if someone can read, store and test the data they produce. The three tools below cover that work: one for component and vulnerability tracking, one for generating and scanning SBOMs, and one for recording assessments against the framework. Each card notes the license terms and the checks to run before relying on it.

OWASP Dependency-Track for SBOM analysis

Dependency-Track consumes and produces CycloneDX SBOMs and VEX documents, so it can receive supplier SBOMs and keep them as a continuing record. It flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. For GV.SC-05, the practical question is whether each supplier can deliver a current SBOM in CycloneDX format for the critical products named in the contract. Confirm that the license data your suppliers provide uses SPDX identifiers, because the tool's license reporting depends on them. The software is licensed under Apache-2.0, and self-hosting it keeps supplier SBOMs inside your own environment.

Trivy for SBOM generation and scanning

Trivy identifies OS packages and software dependencies in a target and can produce them as a software bill of materials. It can also scan an existing SBOM, which helps when a supplier delivers an SBOM instead of a running system. Use it to test whether a supplier's delivered SBOM matches what is actually present in the product image or artifact, which is a stronger check than accepting the document as written. Ask suppliers which artifacts they will hand over, such as container images, packages or firmware images, because Trivy's coverage depends on the target type. The project is licensed under Apache-2.0.

CISO Assistant for framework evidence

CISO Assistant ships more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2 and DORA, and runs audits and compliance assessments against them with automatic mapping between frameworks. For GV.SC-05, it can hold the supplier clauses, their status and the evidence received, such as attestations or certifications, against the CSF Subcategory. Its license is AGPL-3.0-only, which carries source disclosure obligations if you modify and provide the software to others, so have counsel review the terms before deploying it for a supplier-facing service. Confirm that the framework version and mappings you need are present in your release, since automatic mappings are a starting point for your own review.

Who owns the contract work, who can outsource it and what the auditor does

Your organization owns its supplier contracts, the criticality decisions behind them and the controls they describe. Procurement and legal decide which terms are negotiable, what fallback positions are acceptable and who signs. The security team and the owner of supplier criticality decide which suppliers need which requirements, because those decisions depend on the data a supplier handles, its access to systems and how important its product or service is to the business. No outside party can accept a risk on your behalf.

Criticality tiers: Confirm that each supplier tier has a documented list of required clauses, so contract language follows a decision rather than a template default.
Clause approval: Legal and security sign off on the clause library, including vulnerability disclosure, SBOM delivery and evidence rights.
Negotiation authority: Name who can accept a deviation and who must review it, and record exceptions with a expiry date.
Contract register: Keep a record of which agreements contain which obligations so monitoring under GV.SC-07 can check them.
Operational owners: Assign a named owner for each supplier obligation, such as SLA reporting or patch notification.

Before signing, check that every critical supplier contract names the evidence you will receive and the person who reviews it.

Where supplier contracts usually fall short and how to close each gap

Most supplier contracts were written before GV.SC-05 existed as a requirement, or were written once and reused for everyone. The six gaps below recur across legacy agreements and new templates alike, and each one leaves the organization without a usable way to verify supplier security. Each card names one gap and the single action that closes it.

Legacy contracts with no security schedule

Many agreements signed before a supplier security program existed have confidentiality and liability clauses but no security requirements at all. GV.SC-05 expects requirements to be set and built into contracts, so an agreement without them gives the organization no basis to ask for evidence. Review the highest-criticality suppliers first, using the list produced under GV.SC-04, and check whether each contract names any security obligation. Where none exists, attach a security schedule through the amendment or renewal process rather than waiting for the next full renegotiation.

One generic clause for every supplier

A single boilerplate security clause applied to a cloud host, a payroll bureau and a office stationery vendor sets the bar too high for some and too low for others. NIST's Implementation Examples for GV.SC-05 call for requirements set by criticality, so the depth of obligations should follow the data, access and business importance each supplier carries. Build two or three tiers of schedule, assign each supplier to a tier from its criticality rating, and record the tier in the contract so that audits can confirm the match.

SBOM clauses with no format or refresh cycle

A clause requiring a bill of materials is only useful if it states the format, the scope and how often it must be refreshed. Without these details, suppliers may deliver a PDF list that cannot be ingested by scanning tools. Specify a machine-readable format such as CycloneDX or SPDX, the products covered, and a delivery trigger tied to each release. The OWASP Dependency-Track tool consumes CycloneDX SBOMs and VEX data, so confirm that the format named in the contract is one your scanning pipeline can read.

Disclosure terms with no named contact

A clause stating that the supplier will report vulnerabilities promptly gives the organization no route to receive the report. The contract should name a security contact role, a monitored intake channel and the information the supplier must include, such as affected versions and available fixes. GV.SC-05 covers vulnerability disclosure clauses, and the GV.SC-08 incident process depends on the same contact. Confirm the address works by sending a test message during onboarding, and record who receives it on the organization side.

SLAs with no measurement method

Security service levels such as patch timelines or incident notification windows are often written as targets with no defined way to measure them. The contract should state the start and end points of each clock, the data source used to verify it, and the remedy when a target is missed. For example, a notification window must say whether it runs from the supplier's detection or from the moment it confirmed the event. Ask the supplier which logs or tickets will prove each measurement before signing, and agree on the reporting format.

Evidence requirements signed but never collected

Clauses requiring attestations, certifications or audit reports are frequently signed and then forgotten, so no evidence arrives when renewal or assessment comes around. Each evidence item should have a named owner on both sides, a due date tied to the contract calendar, and a stated consequence for late delivery. Set up a register that tracks each required document per supplier, and review it against the reviews planned under GV.SC-07. Evidence that is never collected offers no assurance, however carefully the clause was drafted.

Common questions about GV.SC-05 contract requirements

How much effort does writing supplier security clauses take?

The effort depends mostly on how many suppliers need new or revised language and how much of your existing contract template you can reuse. Start by listing suppliers by criticality, since GV.SC-05 expects requirements set by criticality, so a small set of critical suppliers may need detailed clauses while lower-tier suppliers receive a standard baseline. The work usually includes drafting default language, mapping each clause to the outcome it supports, and agreeing on evidence. Drivers that raise the effort include multiple contract templates, suppliers that resist negotiated terms, and clauses that need technical input on bills of materials or vulnerability disclosure. Ask any firm to break its quote into template work, per-supplier work and negotiation support so you can see where the hours go.

How long does a contract refresh usually take?

The duration is set by the number of contract families, the review path inside your organization and how quickly suppliers respond, so no single timeline applies. Refreshes tend to run longest when legal review, procurement approval and supplier negotiation happen in sequence rather than in parallel. Renewal dates also shape the schedule: clauses added at renewal move faster than clauses that require reopening active agreements mid-term. Ask for a written schedule with milestones for template approval, supplier outreach and renewal cut-over, and confirm which steps depend on your legal and procurement calendars rather than on the implementation partner.

Can an internal team write these requirements without a partner?

Yes, an internal team can write GV.SC-05 requirements if it has access to legal counsel, a current supplier inventory and people who understand the systems and data each supplier touches. Many organizations draft the baseline clauses internally and bring in outside help only for technical clauses such as software or hardware bills of materials, vulnerability disclosure timelines and evidence of security practices. The gap to watch is consistency: if each contract owner writes different wording, your assessor will find it harder to show that requirements were set and applied by criticality. A partner can help with template design and tooling, while your organization keeps ownership of the final terms.

What does the work need from procurement and legal?

Procurement and legal own the contract instruments, approval thresholds and negotiating position, so their participation is required before any clause reaches a supplier. Legal reviews whether the language is enforceable under your governing law and whether it conflicts with existing master agreements. Procurement supplies the supplier register, renewal calendar and standard terms, and decides how new requirements affect pricing and onboarding. Security and the business owner set the criticality rating that determines which clauses apply. Ask who signs off each clause type before work starts, because unclear approval rights are a common reason refreshes stall.

Does NIST certify supplier contract language against CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Contract language that reflects GV.SC-05 is therefore a voluntary alignment decision, not a certified state. Independent auditors and assessors can test whether your clauses and their application support the outcome, but they do not issue a NIST certificate. When a customer asks for proof, offer the executed contract templates, the criticality mapping and the evidence you collect from suppliers, and confirm with the requesting party which assessment format they accept.

What will an auditor sample when testing supplier contract requirements?

An auditor typically samples a set of supplier agreements across criticality levels and checks whether the required clauses are present and whether the organization collected the evidence they promise. Expect requests for the criticality ranking that drives the requirements, the default contract language, executed agreements for critical suppliers and records showing vulnerability disclosure contacts, bill of materials deliveries and attestations or certifications received. The sample is selected by the auditor, so keep contract records in one retrievable location and confirm the test approach and sample sizes with your independent assessor before fieldwork starts.

How do open-source tools help produce evidence for these clauses?

Open-source tools can produce the technical evidence that certain clauses ask for, but they do not write the contract. For clauses requiring a current software bill of materials, Trivy (Apache-2.0) can identify OS packages and software dependencies in a target and produce them as an SBOM, and it can also scan existing SBOMs. OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities and tracks license use by SPDX identifier, which helps you check supplier deliverables over time. Confirm with each supplier which SBOM format they can deliver before you specify it in the clause.

How DeployOpen prepares supplier security evidence for GV.SC-05

DeployOpen helps organizations prepare the supplier security terms and the evidence behind them for GV.SC-05, the requirements set in contracts and other agreements with suppliers. The organization keeps ownership of its contract language, criticality decisions and supplier relationships, while DeployOpen prepares the systems, records and documentation those terms depend on.

How we scope

Agree in writing which supplier-facing systems, product inventories and contract templates fall inside the engagement
Confirm with the organization which supplier tiers and criticality levels the requirements must cover
List the evidence each agreed requirement should produce, such as SBOM exports, vulnerability disclosure records or attestations

How we build

Configure self-hosted tooling such as Dependency-Track to ingest CycloneDX SBOMs and track vulnerabilities by component
Set up Trivy scanning of organization-owned software and existing SBOMs so product component records stay current
Map contract requirements to GV.SC-05 Implementation Examples and the related control references for audit traceability

How we hand over

Deliver written documentation of the configured tooling, data flows, and evidence collection steps for the agreed scope
Provide a requirement-to-evidence register that shows where each contract clause is supported in practice
Give the organization's own team the runbooks it needs to keep SBOMs and supplier evidence current after handover

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer for systems DeployOpen has deployed
Confirm with your auditor or assessor which evidence formats they will accept before the engagement begins