What GV.SC-04 asks for and why a supplier record comes first
A customer questionnaire, a regulator's examiner or an internal audit asks one question early on: how do you know who your suppliers are, and how do you rank them? GV.SC-04 is the CSF 2.0 outcome that answers it. It sits in the Cybersecurity Supply Chain Risk Management (GV.SC) Category of the GOVERN Function, and in plain words it requires that suppliers are identified and ranked by criticality. It is the successor to CSF 1.1 ID.SC-2, which NIST carried into the 2.0 Core under a new identifier. Under the NIST CSF 1.1 to 2.0 Core Transition Changes spreadsheet, the mapping is direct, so a team that already reported against ID.SC-2 can start from its existing supplier list. The outcome matters because every other supply chain outcome depends on it. Contract requirements, due diligence and monitoring all need a known list of suppliers with a stated criticality to decide how much scrutiny each one gets.
The risk GV.SC-04 addresses is simple to describe and hard to contain. A supplier that nobody has recorded can still hold customer data, run a payroll export or keep a standing administrative connection into production. Shadow SaaS is the usual cause: a team signs up for a tool on a corporate card, and no contract, owner or data classification ever reaches the procurement or security record. Ownership is the second cause. When a supplier is recorded but no named person in the business owns the relationship, nobody notices when its data scope or access grows. Stale lists are the third. A supplier register built once for an audit drifts within months as contracts end, subsidiaries are acquired and cloud accounts multiply. Asking a team to list its suppliers is not enough, because the list will mostly reflect the suppliers they remember.
For a working starting point, ask the organization to answer three questions for each supplier in the record: what data it handles, what access it holds to systems, and how much the business depends on its products or services. These map to the criticality criteria NIST describes in its Implementation Examples for GV.SC-04, which include the sensitivity of data handled, the degree of system access and importance to the mission. Confirm with your own risk owners how those criteria are weighted and who signs off on the ranking, because NIST does not set thresholds. Finding unrecorded suppliers usually needs more than a survey. Compare accounts payable records, single sign-on applications, cloud billing and network egress against the register. The output should be a supplier list with an owner, a criticality rating and a review date for each entry, which is the evidence an assessor will ask to see first.
Which suppliers and records fall inside GV.SC-04
GV.SC-04 asks for a complete record of suppliers, ranked by criticality. The hard part is deciding what counts as a supplier in the first place, because the same vendor can be a hosting provider, a software source and a holder of privileged access at once. The cards below cover the scoping calls that most change how much work the record requires.
Cloud and SaaS providers
Cloud platforms and SaaS applications often hold regulated data without appearing in procurement records, since teams sign up with a corporate card or a click-through agreement. Record each provider as a supplier, with the data categories it stores and the accounts or tenants it runs under. Ask whether any provider sits beneath another, such as a SaaS tool hosted on a third-party cloud, because that dependency belongs in the record too. Confirm the owner for each entry.
Managed service providers
An MSP or MSSP often holds administrative credentials to endpoints, networks or backups, which makes it one of the most privileged suppliers an organization has. Record the provider, the systems it administers, the accounts it holds and any remote access tooling it uses. Because a single provider may cover many systems, its criticality usually rises well above the value of its contract. Check whether the provider's own subcontractors are visible to you.
Software vendors and open-source components
Commercial software vendors belong in the record when they supply products that run in your environment, receive updates from them or depend on their license servers. Open-source projects are usually not a contracted supplier, but the organization still depends on the maintainers and the hosting repositories. Decide whether to record the project as a supplier, a component, or both, and state that choice in the methodology so assessors can follow it.
Hardware suppliers
Hardware suppliers matter for GV.SC-04 when they supply devices with firmware, network equipment, storage or hardware that connects to sensitive systems. A reseller and the original manufacturer may be different parties, and both can affect risk. Record the supplier relationship that the organization actually manages, then note where a manufacturer's firmware or update channel creates an additional dependency. Hardware with long life spans should be reviewed when the supplier changes.
Contractors with system access
Individual contractors and staffing firms with system access are suppliers in the GV.SC sense, even when no product is delivered. Record the firm, the people it provides, the systems they can reach and whether their accounts are separate from employee accounts. Access granted to a contractor often outlives the project, so check the record against current account lists. Criticality should follow the access level, not the size of the contract.
Suppliers that handle data without a contract
Some suppliers receive or process organizational data without a signed agreement, such as a free analytics tool, an outside consultant using personal accounts or a partner that receives files by email. These relationships are easy to miss in procurement systems and are often the ones with the least control. Search expense reports, network traffic, data sharing logs and business unit inventories to find them. Once found, record them and rank them the same way as contracted suppliers.
How an assessor tests whether suppliers are known and prioritized
An assessor testing GV.SC-04 is looking for three things: a supplier record that matches reality, criteria for criticality that are written down and actually applied, and a ranking that other supply chain activities depend on. The supplier record is the starting point. The assessor will sample suppliers from the accounts payable ledger, the contract register and the list of systems with third-party connections, then check whether each appears in the record with an owner, the services provided and the data or systems involved. Gaps in either direction matter: a supplier with live access that is missing from the record is a finding, and so is a record entry for a vendor nobody can explain.
The criticality criteria are the second test. NIST's Implementation Examples for GV.SC-04 point to three factors: the sensitivity of data the supplier handles, the degree of access it has to systems, and how important its product or service is to the mission. An assessor will ask for the written criteria, the scoring or tiering method, and evidence that the ranking was applied to real suppliers. Ask the people who own the record to walk through two or three suppliers, showing how each factor was scored and who approved the result. Vague labels such as "high" with no stated basis usually fail.
Because NIST's CSF 2.0 is voluntary and NIST offers no conformity assessment program, no official body issues a GV.SC-04 certificate. The assessor is therefore usually a customer running due diligence, an internal audit function, or an independent reviewer who uses the Subcategory as the test objective and reports against it. Confirm the scope and method in writing before fieldwork begins, including which systems and supplier populations are sampled. The NIST CSF 2.0 Reference Tool export lists informative references that a reviewer may cite, but those references are supporting material, not pass criteria set by NIST.
What assessors ask for and where findings usually land
This table compares what an assessor typically tests for GV.SC-04, the evidence they request, and the findings that appear most often. Read each row as a test the organization should rehearse before an assessment, since the gaps tend to sit in the supplier record and the criteria behind it.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Supplier inventory completeness | Exported supplier register with owner, service and data categories, reconciled against accounts payable, procurement records and cloud subscriptions | Shadow suppliers such as SaaS tools bought on corporate cards are absent from the register |
| Written criticality criteria | Approved document defining how criticality is scored, including data sensitivity, degree of system access and mission importance | Criteria exist only in a slide deck or a meeting note and no one can show who approved them |
| Sample of ranked suppliers | Ranking records for a selected sample, with the scoring inputs that produced each rank and the reviewer's sign-off | Ranks cannot be traced to the criteria, or high-access suppliers are ranked low without a recorded reason |
| Link between ranking and oversight | Contract tiers, assessment frequency and monitoring settings mapped to each criticality level | Critical suppliers receive the same questionnaire as low-risk ones, so the ranking changes nothing in practice |
| Record currency | Change history showing re-ranking after new onboarding, scope changes, material incidents or ownership changes | Rankings are set once at onboarding and not refreshed after a supplier gains access or handles new data |
How to build a supplier record that ranks suppliers by criticality
This sequence turns scattered supplier information into one reconciled register in which every supplier has a documented criticality tier, an accountable owner and a rule for when that tier gets reviewed.
Define the criticality criteria
Write a short criteria document that sets out how suppliers are judged on three factors: the sensitivity of the data they handle, the degree of access they hold to systems and networks, and how important their products or services are to the mission. Business owners, the security lead and the risk function agree on the wording, and each factor gets defined tiers with examples from the organization's own environment. NIST's Implementation Examples for GV.SC-04 use these same factors, so the document can point back to them. The output is an approved criteria document with a named approver and a version date.
Assemble the supplier inventory from source systems
Pull supplier names from several independent sources rather than relying on one list: accounts payable and finance records, procurement and contract repositories, identity provider application lists and single sign-on connections, and asset records of software, cloud services and hosted tools. Each source will name suppliers differently, so group duplicates under a single legal entity and note which sources reported each supplier. Suppliers that appear only in finance or only in identity systems are the usual gaps and should be followed up with the budget holder. The output is a consolidated, de-duplicated candidate list with source references.
Reconcile the list into one supplier register
Compare the candidate list against contracts and onboarding records to decide which entries are active suppliers, which have ended, and which are internal teams or subsidiaries that should not be scored. For each active supplier, record the legal name, the service or product provided, the systems and data involved, and the contract reference. Discrepancies between sources are resolved by the procurement lead and logged with the decision. The output is a reconciled supplier register with one row per supplier and a log of every exclusion.
Classify each supplier against the criteria
Score every supplier in the register against the three criteria, using the tiers defined in step one. Where a supplier handles several kinds of data or holds several access paths, assign the highest tier that applies rather than an average, and note the evidence used, such as a data flow diagram, an access grant or a service description. Suppliers that cannot be classified because the evidence is missing are flagged for follow-up rather than given a default tier. The output is a classified register in which each row shows a criticality tier and the evidence behind it.
Rank suppliers and record owners and rationale
Sort the classified register from highest to lowest criticality, and within each tier order suppliers by the strength of their access or data exposure. Assign a named internal owner to every supplier, usually the business lead who manages the relationship, and record a short rationale sentence that explains the tier in plain language. Owners who cannot be named are escalated to the risk function because an unowned critical supplier is an accountability gap. The output is a ranked supplier list with an owner and rationale for every entry.
Set review triggers and approve the register
Define the events that force a supplier to be reclassified, such as a new data category, a change in access scope, a merger or change of control, a significant incident at the supplier, or a new contract. Add a scheduled review cadence for the whole register and state who is notified when a trigger fires. The security lead and the accountable executive then approve the register, and the approved version is stored where audit evidence is kept. The output is an approved register with a documented trigger list and review record.
Evidence that proves suppliers are known and ranked
GV.SC-04 is met on paper by a current supplier register, approved criticality criteria and a dated ranking. Assessors then test whether those records reconcile with finance and asset data and whether changes to rankings leave a trail. The cards below cover each artifact and how the owner keeps it current between assessments.
Supplier register with owners and data
The register is the single list of suppliers in scope, with one named internal owner per supplier, the service provided, the categories of data the supplier handles and the systems or network paths it can reach. Check that every supplier appears, including cloud services and managed providers that were bought through business units. Review the register at least once a quarter and whenever a contract is signed, renewed or ended. Ask who is accountable for adding entries when procurement is bypassed.
Approved criticality criteria
Criticality criteria are the written rules that decide how a supplier is ranked. NIST's Implementation Examples for GV.SC-04 point to three factors: the sensitivity of data handled, the degree of system access and importance to the mission. Store the criteria as an approved document with a version, an approver and a review date. Confirm that each tier has a definition an assessor can apply to a real supplier without interpretation.
Dated ranking output
The ranking is the result of applying the criteria to each register entry, recorded with the date it was assessed and the person who approved it. Each supplier should carry a tier and the reasoning behind it, so the decision can be defended later. Confirm that the ranking covers the whole register, not a sample, and that unranked entries are flagged rather than silently left out.
Reconciliation against finance and asset data
Reconciliation compares the register with accounts payable records, contract databases and the asset inventory. Gaps usually appear as software-as-a-service subscriptions paid by corporate cards or systems running on infrastructure no one has listed. Open-source inventory tools such as GLPI and Wazuh can show installed software and assets that a supplier may touch, which helps close those gaps. Record each reconciliation run, the differences found and who resolved them.
Change log for re-ranking
A change log records every move between tiers, every new supplier added and every supplier removed, with the reason and the approver. Re-ranking is usually triggered by a new data category, a change in system access, a merger or a supplier that becomes a single point of failure. Keep the log in the same system as the register so the history cannot be edited separately. Check that a sample of changes traces back to a documented trigger.
Review triggers and named owners
Between audits, the evidence stays current only if each artifact has an owner and a defined trigger for review. Typical triggers include contract signature or renewal, a security incident involving a supplier, a change in the data a supplier handles and a scheduled review of the criteria. Assign one owner for the register, one for the criteria and one for reconciliation, and write those roles into the supplier risk policy. Ask the assessor to test whether the owners can show their last review.
What meeting GV.SC-04 costs in money and effort
This table breaks down the cost components of building and keeping a supplier register ranked by criticality, marking each as one-time or recurring and naming what drives it up. No price or duration figures were supplied, so the right-hand column tells you what to request in a quote or measure in your own environment. Read it as a checklist for scoping internal effort against any outside help.
| Cost component | One-time or recurring | What drives it up | What to ask for in a quote |
|---|---|---|---|
| Criteria workshops (internal time) | One-time, revisited on review | Number of business units and data owners who must agree on criticality factors such as data sensitivity, system access and mission importance | Named workshop sessions, attendees by role, and the written criticality criteria each output will contain |
| Supplier discovery and reconciliation | One-time, then recurring as suppliers change | Supplier count, fragmented purchasing across departments, and shadow SaaS or cloud accounts nobody registered | Method for pulling suppliers from finance, procurement, identity and cloud billing records, and how duplicates and subsidiaries are merged |
| Tooling or licenses | Recurring where commercial software is used | Commercial GRC or third-party risk platforms priced by user, supplier or module count | Itemized license terms, renewal dates, user and supplier limits, and what is included in the base fee. Self-hosted open-source options such as GLPI can remove license spend, but hosting and administration effort remain |
| Initial classification effort | One-time per supplier, then on change | Data sensitivity mix, depth of system access, and how many suppliers touch critical services | Proposed classification tiers, the evidence each tier requires, and who signs off each rating |
| Recurring register upkeep and review | Recurring | Frequency of supplier onboarding and offboarding, mergers, and how often criticality is re-scored | A named owner, the trigger events for re-ranking, and the review cadence written into the register procedure |
| Integration with asset and system inventory | One-time setup, recurring data feeds | Number of systems linked to each supplier and whether supplier access is recorded in identity or asset tools | Data sources to be linked, how supplier-to-system mappings are maintained, and the export format for assessors |
| Optional external review | One-time or periodic | Scope of the review, regulatory expectations on the organization, and the number of suppliers sampled | Fixed scope and deliverables in writing, what the reviewer will test, and confirmation that the reviewer prepares evidence but does not issue an assessment opinion |
Which self-hosted tools can support the supplier evidence
CISO Assistant is an open-source governance, risk and compliance platform (AGPL-3.0-only) that ships with more than 200 frameworks, including NIST CSF. For GV.SC-04, its value is in organizing the assessment around the outcome: you can record the supplier criticality criteria, link the supplier register and the risk items that drive a ranking, and run an assessment against the CSF 2.0 structure. Its automatic mapping between frameworks can help show where the same supplier evidence also supports other frameworks you are asked to meet.
- Assessment records: Run and store an assessment against the NIST CSF framework, with the GV.SC-04 outcome linked to the evidence you attach.
- Criticality criteria as records: Hold the agreed criteria for data sensitivity, system access and mission importance so reviewers can see the basis for each ranking.
- Framework mapping: Use the automatic mapping to see related requirements in other frameworks you are asked to meet, then confirm each mapping with your assessor.
- Evidence attachments: Store the approved supplier register extract, review minutes and sign-off records as supporting evidence.
- Scope limits: The platform holds and organizes records; it does not discover suppliers or decide criticality for you.
Confirm in your own environment which framework versions and mappings your installed release includes, and whether the supplier register can be imported or must be maintained as a linked document.
GLPI is an open-source IT service management platform (GPL-3.0-or-later). Its Assets module manages computers, software, network equipment, printers, phones, racks and other items, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. For GV.SC-04, GLPI helps you reconcile technology suppliers and services against what is actually in use, such as the vendor, the product and the device that a service depends on. It is most useful when the supplier record and the asset record point to each other.
- Asset records: Hold hardware and software items with fields that can name the vendor or the service provider responsible for them.
- Automatic inventory: The GLPI Agent can push device and software data, which helps confirm that a supplier-provided item is really deployed.
- Reconciliation: Compare the supplier list with asset records to find suppliers that have no linked assets or assets with no known supplier.
- Ownership fields: Record who inside the organization owns each supplier relationship, so the register links to a named person.
- Scope limits: GLPI tracks assets, not the commercial, data-handling and access attributes that determine criticality.
Confirm the available asset types, custom fields and supplier-related options in your GLPI version, and check how the agent's inventory data is refreshed in your environment.
Wazuh is an open-source security monitoring platform (GPL-2.0-only). Its Syscollector module collects inventory from each endpoint, including hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates, then stores it in the Wazuh indexer for views and reports in the dashboard. For GV.SC-04, this evidence shows technical dependencies, such as third-party software and services running on endpoints. It does not show the supplier register itself.
- Software inventory: Lists installed packages and versions that you can trace back to the vendors responsible for them.
- Service and process visibility: Shows running services and listening ports, which can reveal supplier-managed components or agents.
- Dependency evidence: Supports the claim that a supplier's software is in use, which helps decide how critical that supplier is.
- Reports: Dashboard views and reports can be exported as evidence of inventory at a point in time.
- Scope limits: Syscollector covers monitored endpoints only. Cloud services, SaaS and suppliers that do not install agents will not appear.
Confirm which operating systems and endpoints are enrolled, the collection interval you have configured, and whether the inventory covers the systems your critical suppliers touch.
A supplier register is a business record. It names each supplier, the service or product provided, the data and systems involved, the business owner and the criticality ranking with its rationale. Tools can store and organize parts of that record and produce evidence for it, but they cannot decide which suppliers matter most, approve a ranking or accept responsibility for it. That judgment belongs to the organization, and independent assessors will look for the approval trail as well as the list.
- Ownership: A named accountable person must approve the register and each ranking.
- Completeness: Tools only see what is entered or what agents can reach, so procurement and contract records are also needed.
- Rationale: The reasons behind each criticality level, tied to data, access and mission importance, must be written down.
- Review cycle: Set how often the register and rankings are reviewed and keep dated records of each review.
- Data sources: Combine the asset, inventory and assessment outputs with contracts and finance records to find suppliers that appear in none of them.
Before relying on any tool for this outcome, confirm each capability in your own environment with a test extract and have your auditor review the evidence chain.
Where organizations fall short on supplier inventories
Most supplier registers fail in predictable places: nobody owns them, purchasing bypasses them, and the rankings never leave the spreadsheet where they were created. Each gap below breaks the link between knowing a supplier exists and knowing how much risk it carries, which is the outcome GV.SC-04 asks for.
No owner for the register
The supplier list often lives in procurement, legal, finance or a security analyst's spreadsheet, with no named person accountable for keeping it complete. Without an owner, new suppliers are added late or not at all, and departed suppliers stay listed as active. Check that one role is accountable for the register, that the role is written down, and that someone can name the last review date and the people who contribute to it.
Shadow SaaS outside procurement
Teams often sign up for cloud tools with a corporate card or a free trial, so the supplier never passes through a purchasing review. These services can hold customer data and connect to production systems while missing from the register entirely. Compare expense records, single sign-on logs and network egress data against the register to find suppliers that were never recorded.
Criteria that stop at the register
Teams may define criticality by data sensitivity, system access and mission importance, yet those criteria rarely reach the contract template, the due diligence checklist or the monitoring schedule. The result is a ranking that exists on paper while critical suppliers receive the same review as minor ones. Ask whether the contracts and monitoring teams can see each supplier's ranking and the criteria behind it.
Rankings frozen after onboarding
Suppliers are often ranked once, at onboarding, and never revisited, even after they gain access to more data, take on a new service or become sole providers for a business process. A supplier that was low risk when first engaged may now be critical. Set a trigger for re-ranking on scope changes, such as new data types, new integrations or new business owners.
Data access without a contract
Some suppliers receive customer records, credentials or network access under a free service agreement, a purchase order with no terms, or a handshake arrangement with a project team. Because no contract exists, the organization cannot require security terms or incident notification. Cross-check the register against access reviews and data flow maps to find suppliers with access but no signed terms.
No evidence of who approved the ranking
A ranking without a recorded approver cannot show that a qualified person reviewed the criteria and accepted the result. Assessors and customers ask for this record because it shows the ranking was deliberate rather than assumed. Confirm that each ranking carries the approver's name, the date, the criteria version applied and the rationale for any override.
Questions buyers ask before building a GV.SC-04 supplier record
How long does it take to build a complete supplier record?
No researched figure exists for this, so treat any duration as something to confirm in the written scope. The time depends on how many suppliers exist, how many of them have contracts that are easy to find, how many business units buy services outside central procurement, and how much data each supplier record needs to hold. The first pass usually goes fastest when procurement exports its supplier master and accounts payable vendor list, and the slowest part is reconciling the two, because shadow purchases, cloud subscriptions on corporate cards and departmental tools often appear in neither. Ask the partner to state the reconciliation method, the number of source systems and the sign-off points before agreeing on a timeline.
Can an in-house team build the supplier record without outside help?
Yes, many organizations do this internally, and GV.SC-04 does not require a specific tool or a partner. The main questions are whether someone can own the inventory across procurement, finance, IT and business units, and whether that person can apply consistent criteria for criticality. Internal teams usually struggle with completeness rather than with the ranking itself. Outside help is most useful when the organization needs a repeatable criticality method, a configured system to hold the record, or a documented process an assessor can follow. A partner prepares the system and the evidence, but the organization still owns the supplier decisions.
What do procurement, security and business owners need to contribute?
Each group supplies a different part of the record:
- Procurement supplies contract registers, supplier master data and the list of purchasing channels.
- Security supplies the criteria for data sensitivity and system access, and checks which suppliers hold credentials, network connections or administrative rights.
- Business owners confirm which services their processes depend on and how serious an outage would be.
The organization should name one accountable owner for the record and agree who approves a supplier's criticality rating. Without that agreement, ratings drift between departments and the record stops being useful to assessors.
Does NIST certify that an organization complies with 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. The CSF is a voluntary framework, so a supplier record built against GV.SC-04 shows alignment with that outcome, not a NIST certificate. Customers or regulators that ask for CSF alignment usually want evidence that you assessed your own position, so be clear in your answers about what you can show and how you measured it.
Can a partner issue a certificate for the supplier record?
No. A partner such as DeployOpen can plan, configure and document the supplier record and the evidence behind it, but only an independent auditor, assessor or certification body issues reports or certificates. If a customer or regulator asks for independent confirmation of your CSF alignment, that work belongs to a qualified outside assessor. Ask any firm you evaluate to state clearly which parts of the work it performs and which parts remain with the organization and its assessor.
How should I size a quote for this work?
DeployOpen does not publish a price list, and a quote follows from a written scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To compare quotes, ask each provider to list the number of suppliers in scope, the source systems to reconcile, the criticality criteria to design, whether a system must be configured or only documented, the evidence deliverables, and what happens after handover. One-time work covers the initial inventory and ranking. Recurring costs arise when the record must be kept current, which can be handled internally or through an ongoing support retainer.
Which tools can hold the supplier record, and what should I confirm about them?
The record does not have to live in a specific product, but it needs a stable place for supplier identifiers, criticality ratings and access details. Open-source options such as GLPI can manage asset records, and tools such as CISO Assistant can run audits and compliance assessments across frameworks, including NIST CSF. Confirm with the vendor whether each tool supports the fields you need for supplier data, not just hardware and software assets, before relying on it. Describe the capability you need in your scope document and verify it in the proof of concept.
Official NIST sources for GV.SC-04
Start with the Core text in Appendix A of CSWP 29, the NIST publication that defines the CSF 2.0 Core. GV.SC-04 sits in the GV.SC Category of the Govern Function, and its outcome wording is the baseline your supplier register has to meet. Read the Subcategory statement itself before you read any guidance built on it, because the statement is what an assessor will hold your records against. The publication is available as a PDF from the NIST CSWP 29 document, and the same Appendix A is the reference for the Subcategory identifier you will cite in your policies and assessment worksheets.
The implementation examples and informative references for GV.SC-04 are not in the framework document. They are published separately, so NIST can revise them without reissuing CSWP 29. Download the NIST CSF 2.0 Reference Tool export and filter for GV.SC-04. The export lists two Implementation Examples covering supplier criticality criteria and a record of all suppliers ranked against them, plus the SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022, SP 800-171 Rev. 3 and CIS Controls v8.1 references. Confirm the export date against the current NIST release before you cite it, since the examples are the part of the material most likely to change.
If you are moving an existing program from CSF 1.1, check the ID.SC-2 to GV.SC-04 mapping in NIST's CSF 1.1 to CSF 2.0 Core Transition Changes spreadsheet. Any supplier inventory, criticality ranking or evidence file tagged to ID.SC-2 in an older assessment should be re-tagged to GV.SC-04 so that the history is not lost. Record the mapping decision in your change log, and ask your assessor to confirm that the evidence they test is the same evidence you carried forward.
