GV.SC-06 says planning and due diligence are performed to reduce risks before entering into formal supplier or other third party relationships. Look before you sign. The earlier you find a problem, the cheaper it is to avoid.
What good looks like
A due diligence step sits in procurement and cannot be skipped. Depth scales with risk, criticality and complexity. Reviewers check the supplier's technical and cybersecurity capabilities and its risk management practices. For critical products, authenticity, integrity and security are assessed before acquisition and use.
NIST's examples are specific: thorough due diligence consistent with procurement planning and commensurate with risk, assessment of the suitability of technology and cybersecurity capabilities and risk management practices, supplier risk assessments against business and applicable cybersecurity requirements, and assessment of the authenticity, integrity and security of critical products prior to acquisition and use.
How to implement it
- Start from tiers (GV.SC-04). Define the due diligence package for each tier. Tier three might be a short checklist. Tier one might include a questionnaire, review of independent assessment reports, a look at the supplier's security and trust pages, and a technical discussion.
- Plan early. Add security to the procurement timeline so reviews happen before the legal negotiation, not after.
- Assess capabilities. Ask how the supplier handles access control, encryption, vulnerability management, incident response and their own suppliers. Ask for evidence, not only answers.
- Assess against your requirements. Compare responses with the contract terms you plan to demand (GV.SC-05) and record gaps.
- Verify critical products. For software, check where it comes from, whether it is signed, what components it contains and whether those have known vulnerabilities. For open source packages you plan to depend on, look at maintenance activity, ownership and published advisories.
- Make a decision and record it: approve, approve with conditions, or decline. Record conditions with owners and dates.
- Keep the file. It is the starting point for ongoing monitoring.
Evidence to collect
- The due diligence procedure and tiered checklists.
- A completed review file for each critical supplier, with the decision and conditions.
- Evidence of product checks, such as software bill of materials review or vulnerability scan results.
- Procurement records showing review happened before signature.
Common gaps
- Due diligence happens after the contract is signed or the tool is in use.
- Questionnaires are collected and filed, with no one scoring them.
- Answers are accepted without evidence.
- Open source packages are adopted with no check at all.
- Conditions are agreed and never followed up.
Checking software before you adopt it
When the thing you are buying is code, or the thing you are adding is a package, you can look inside. Before adoption, list the components and check them for known vulnerabilities. The free in-browser dependency scan at https://gold.safeguard.sh/scan lets you do this in a minute without giving repository access, and reachability analysis helps show whether a vulnerable component is actually called by the code.
Scaling the review
A tier three tool might get a fifteen minute checklist from the buyer. A tier two supplier might get a questionnaire and a look at its published security documents. A tier one supplier gets the full package, including a follow up call and a conditions list. Writing these three levels down means procurement can run the first two without waiting for security, and security can focus on the handful of suppliers that matter.
Quick check
How deep should due diligence go for a small supplier?
Match depth to risk. If the supplier touches no sensitive data and has no system access, a short checklist is enough.
What counts as evidence?
Independent assessment reports, policy documents, test summaries, a trust page with dated artifacts, or a live walkthrough. A yes in a questionnaire is a claim, not evidence.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.SC-06: https://csrc.nist.gov/projects/cybersecurity-framework/filters
- NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework
The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.
