GV.SC-06: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships

The target keyword for this requirement page is gv.sc-06: planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships requirement. In practice, GV.SC-06 is a “pre-engagement control”: it forces discipline before Procurement signs, before Legal finalizes terms, and before IT provisions access. If you treat it as a paperwork step after onboarding, you will fail the intent and struggle to defend decisions during an audit.

GV.SC-06 sits in the NIST CSF 2.0 Governance domain and focuses on supplier and third-party risk in the supply chain. The requirement is short, but the operating model behind it must be explicit: who initiates due diligence, what triggers it, what “pass/fail” means, how exceptions are handled, and what evidence proves the work happened before the relationship became formal.

This page gives requirement-level guidance you can implement quickly: a practical workflow, decision points, required artifacts, and common audit questions. It also includes a phased execution plan that helps you stand up an enforceable intake-and-approval gate without stalling the business.

Regulatory text

NIST CSF GV.SC-06 excerpt: “Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships.” (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes)

Operator interpretation: before you sign, renew, or materially expand a third-party relationship, you must (1) plan what you need from the third party and what risks matter, (2) perform due diligence proportionate to the risk, and (3) use the results to reduce risk through contract terms, technical controls, onboarding conditions, or a no-go decision. (NIST CSWP 29)

Plain-English interpretation (what GV.SC-06 means day-to-day)

GV.SC-06 is satisfied when your organization can prove three things:

1. You ran due diligence before commitment. “Formal relationship” includes signing a master services agreement, statement of work, purchase order with material terms, renewal, or granting production access that effectively commits you to the third party.
2. The diligence matched the risk. A payroll processor, cloud hosting provider, and outsourced SOC should face deeper scrutiny than a low-impact training provider.
3. You acted on what you found. Findings must drive risk treatment: contract clauses, remediation plans, compensating controls, restricted access, or rejecting the third party.

Auditors and examiners usually focus less on your questionnaire format and more on whether your process reliably prevents “deal-first, assess-later.”

Who it applies to

Entities: Any organization running a cybersecurity program that relies on suppliers or other third parties for systems, data processing, operations, or security-relevant services. (NIST CSWP 29)

Operational scope (include these relationships):

• Third parties that store, process, transmit, or can access your data (customer, employee, financial, regulated, or proprietary).
• Third parties that provide technology or security services (SaaS, IaaS/PaaS, managed services, incident response retainers, identity providers).
• Suppliers embedded in your product/service delivery (data feeds, call centers, software libraries where you have a commercial relationship, logistics providers with system integration).
• Any third party where failure creates material operational, compliance, or availability impact.

Trigger events (treat as “new relationship” for GV.SC-06 purposes):

• New third party onboarding.
• Renewal with changed scope.
• Adding new data types, new integrations, new geographies, subcontracting, or elevated privileges.

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

Implement GV.SC-06 as a gated workflow tied to Procurement, Legal, and Identity/Access processes.

Step 1: Define “formal relationship” and set a hard gate

• Document which events require due diligence completion: contract signature, PO issuance above a defined threshold (if you use one), production access, API keys, VPN, SSO, shared credentials, or data transfer.
• Configure a gate in your intake tool (Procurement system, ticketing, or GRC platform): no approval, no onboarding without a recorded due diligence outcome and approver.

Practical tip: The gate must cover “shadow spend” paths, such as credit-card SaaS purchases and business-led trials that quietly become production.

Step 2: Classify the third party and assess inherent risk

Create a short intake that can be completed quickly by the business sponsor:

• Service description and business purpose
• Data types and sensitivity
• Access level (none, limited, privileged/admin)
• Connectivity/integration (manual uploads, API, network)
• Subprocessors/fourth parties (known at the time)
• Business criticality and outage tolerance (qualitative)
• Regulatory impact (where applicable)

Output: an inherent risk tier (for example: low/medium/high/critical) with documented rationale. The point is consistency and defensibility, not perfect scoring.

Step 3: Plan the diligence depth based on risk tier

Create a due diligence “menu” mapped to risk tiers. Example:

Diligence area	Low	Medium	High/Critical
Security questionnaire	Light	Standard	Extended + follow-ups
Independent assurance (SOC 2 / ISO evidence)	Optional	Requested	Required or formal exception
Pen test / vuln mgmt evidence	Optional	Requested	Required for relevant services
Privacy/compliance review	As needed	Yes if personal data	Required
Financial/operational resilience checks	Minimal	Basic	Required
Contract security addendum	Standard	Standard + clauses	Enhanced + rights/audit/IR terms

Keep the mapping simple enough that Procurement and business owners can predict timelines.

Step 4: Execute due diligence and document results

Typical evidence sources:

• Completed questionnaire and documented clarifications
• Attestations and third-party reports shared by the provider
• Architecture/hosting summary, data flow description
• Incident response and breach notification process summary
• List of subprocessors (if relevant to service)
• Results of sanctions/reputational checks if required by your internal policy

Record:

• What was requested
• What was received
• What gaps remain
• Your risk decision and conditions

Step 5: Decide: approve, approve with conditions, or decline

Define decision authority by risk tier:

• Low risk: security reviewer approval
• Medium risk: security + privacy (if applicable)
• High/critical: formal risk acceptance path with accountable executive approval when exceptions exist

Risk treatment options:

• Contractual: security schedule, breach notice, audit rights, data handling limits, subcontractor controls
• Technical: least privilege, network segmentation, token scopes, logging, CASB/SSPM controls, encryption requirements
• Operational: onboarding checklist, incident communications playbook, tabletop coordination, remediation deadlines

Step 6: Bind the decision into contracting and onboarding

Make the due diligence output actionable:

• Provide Legal with a clause checklist tied to the identified risks.
• Provide IT/Identity teams with access constraints (SSO required, no shared accounts, scoped API keys, production access after controls validated).
• Capture “conditions to start” vs “conditions to remediate after start” so the business can’t skip the hard requirements.

Step 7: Retain evidence and schedule follow-on activities

GV.SC-06 focuses on pre-entry, but you should schedule post-entry monitoring (separate from this requirement) so diligence stays current for renewals and scope changes. Maintain a record that the pre-entry gate was satisfied.

Required evidence and artifacts to retain

Auditors want proof that due diligence happened before commitment and that decisions were controlled.

Minimum evidence pack per third party:

• Third-party intake record + inherent risk tier and rationale
• Due diligence checklist tied to the risk tier
• Completed questionnaire and supporting documents received
• Review notes: identified gaps, compensating controls, and residual risk
• Approval record (who approved, date, outcome, any conditions)
• Exception/risk acceptance (if any) with business owner sign-off
• Contract artifacts showing risk treatment (security addendum, DPA where applicable, clause redlines summary)
• Onboarding/access approval showing security conditions were met before provisioning

Program-level artifacts:

• Third-party risk management policy and procedure that defines the gate and roles
• Control ownership and recurring evidence collection plan (aligned to GV.SC-06) (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes)

Common exam/audit questions and hangups

Expect these questions and prepare clean, reproducible answers:

• “Show me three recent third parties and prove diligence was completed before signature or access.”
• “How do you decide diligence depth? Is it consistent across business units?”
• “Who can accept risk, and what stops a project team from bypassing the process?”
• “How do you handle renewals and scope expansions?”
• “Where are due diligence results reflected in contract terms and onboarding controls?”

Hangups auditors flag:

• Evidence timestamps that show contracts signed before approvals.
• A questionnaire exists, but no proof anyone reviewed it or acted on gaps.
• “One-size-fits-all” diligence that fails to distinguish critical providers from low-risk ones.

Frequent implementation mistakes (and how to avoid them)

1. Due diligence after the deal is done.
   Fix: enforce a procurement/SSO gate. If SSO or vendor payment cannot proceed without the approval ID, the process becomes real.

2. Risk tiering without clear inputs.
   Fix: require data type, access level, and integration method as mandatory fields. Those three inputs drive most inherent risk.

3. Contracting disconnected from diligence.
   Fix: create a clause playbook mapped to common findings (logging, breach notice, subprocessors, data location, encryption, audit rights).

4. Exceptions treated as informal emails.
   Fix: use a standard risk acceptance template with explicit owner, scope, rationale, and conditions.

5. No recurring evidence plan.
   Fix: assign a control owner and define what evidence is collected per quarter or per onboarding cycle, then store it in a single system of record.

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. Practically, GV.SC-06 maps to a common failure pattern regulators and auditors scrutinize across industries: third-party incidents where the organization cannot show a pre-contract decision process, documented risk acceptance, or contract controls aligned to identified risks. Treat “missing implementation evidence” as a material program weakness because it undermines your ability to prove governance and oversight. (NIST CSWP 29)

Practical 30/60/90-day execution plan

Use phases instead of date promises; the right pace depends on procurement complexity, contract volume, and current tooling.

First 30 days (Immediate stabilization)

• Name a control owner for GV.SC-06 and publish a one-page standard operating procedure.
• Define “formal relationship” triggers and implement a temporary manual gate (Procurement checklist + Security sign-off).
• Stand up a basic inherent risk intake and a three-tier risk model.
• Create an evidence folder structure and a standard approval record template.

Days 31–60 (Operationalization)

• Build diligence “menus” by risk tier and align them with Legal clause requirements.
• Train Procurement, Legal, IT provisioning, and business sponsors on the gate and required lead times.
• Pilot the workflow on a small set of new third parties and renewals; capture what slowed deals and fix it.

Days 61–90 (Scale and audit readiness)

• Automate intake and approvals in your ticketing or GRC tool so timestamps and approvers are immutable.
• Implement exception handling with formal risk acceptance and an escalation path for high-risk providers.
• Establish recurring evidence collection and metrics that show process adherence (for example: percentage of onboardings with completed approvals) without inventing externally sourced benchmarks.

Where Daydream fits naturally: if you need a single system to map GV.SC-06 to policy, procedure, control owner, and recurring evidence collection, Daydream can function as the control system of record and make audits faster because artifacts are consistently tied to each third party and decision point. (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes)

Frequently Asked Questions

What counts as “planning and due diligence” for GV.SC-06?

It’s the pre-entry work that lets you identify and reduce third-party risk before you commit. That typically includes inherent risk tiering, security/privacy diligence scaled to the tier, documented review, and a recorded approval with conditions.

Does GV.SC-06 apply to non-IT suppliers?

Yes, if the supplier relationship can create cybersecurity risk, such as facility access, device handling, operational technology support, or access to sensitive business information. Treat “third party” broadly and scope diligence to the exposure.

Can we rely on a SOC 2 report alone?

A SOC 2 can be strong evidence, but GV.SC-06 still expects a decision process. You should document how the report maps to your risk concerns, note gaps, and record any required contract clauses or compensating controls.

How do we handle urgent purchases where the business wants to sign immediately?

Use an expedited path with minimum required checks and an explicit risk acceptance if you can’t complete full diligence. Keep the gate intact; the “fast path” should still produce an approval record and defined conditions.

What if the third party refuses to complete our questionnaire?

Decide based on risk tier. For higher-risk third parties, treat refusal as a blocker unless an executive accepts the residual risk and Legal can secure compensating contractual protections.

How do renewals fit into GV.SC-06?

Renewals and scope expansions are new decision points because risk changes over time. Re-run risk tiering and complete enough diligence to cover material changes, then document approval before renewal execution.