GV.SC-07: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship

To meet the gv.sc-07: the risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship requirement, you need an end-to-end third-party risk workflow that starts before onboarding, assigns a risk tier, drives contract/security actions, and continues with monitoring and re-assessment until offboarding, with auditable evidence at each step. ¹

Key takeaways:

• Build one governed process that covers intake, risk scoring, due diligence, risk treatment, and ongoing monitoring across the relationship. ¹
• Keep a living third-party inventory and risk register that ties each third party to services, data access, criticality, and current risk decisions. ¹
• Make the process auditable: named owners, defined triggers, documented decisions, and recurring evidence collection. ²

GV.SC-07 is a supply chain and third-party risk requirement framed for operators: you must be able to show that you know your third parties, understand the risks they introduce, and manage those risks continuously, not as a one-time onboarding checklist. The hard part is operational, not conceptual. Most programs fail because intake is informal, “critical vendors” aren’t defined consistently, and risk decisions live in email instead of a system of record.

This page gives requirement-level implementation guidance you can execute quickly as a Compliance Officer, CCO, or GRC lead. You’ll get a step-by-step workflow, a pragmatic decision structure for tiering and due diligence depth, and a concrete list of evidence an auditor will expect. The goal is simple: if a regulator, customer assessor, or internal audit asks, “Show me how you manage third-party cyber risk over the relationship lifecycle,” you can produce a complete trail from intake to offboarding. ¹

Where relevant, this guidance aligns to NIST CSF 2.0 governance outcomes and emphasizes defensible documentation and recurring evidence collection, which NIST highlights as a practical transition expectation for organizations formalizing cybersecurity governance. ²

Regulatory text

Excerpt (GV.SC-07): “The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship.” ¹

What the operator must do: implement a lifecycle third-party risk management (TPRM) process that (1) identifies third parties and what they do for you, (2) records the risk, (3) prioritizes who gets deeper review and faster action, (4) performs assessments proportionate to risk, (5) drives risk responses (contract, technical controls, governance decisions), and (6) monitors continuously until termination/offboarding. This must be repeatable and evidenced. ¹

Plain-English interpretation (what GV.SC-07 really demands)

You need to answer six questions for every third party that matters:

1. What exposure do they create? (systems access, data types, connectivity, operational dependency)
2. What could go wrong? (security, availability, integrity, confidentiality, compliance, concentration risk)
3. How risky are they compared to others? (tiering/prioritization)
4. What proof do we have? (due diligence results and validation)
5. What did we do about gaps? (risk treatment decisions and actions)
6. How do we know it’s still true later? (monitoring, re-assessment, incident handling, offboarding) ¹

Who it applies to

Entity scope: any organization running a cybersecurity program that relies on external parties for products, services, data processing, infrastructure, development, support, or business operations. ¹

Operational scope (include these, not only “vendors”):

• Cloud/SaaS providers, MSP/MSSP, data processors, payroll/HR platforms
• Consultants/contractors with network or data access
• Software suppliers (including open-source dependencies if you govern them as “third parties”)
• Logistics, call centers, payment processors, and outsourced operational functions
• Fourth parties (material subcontractors) when they meaningfully affect your risk ¹

Trigger points: onboarding/new purchase, renewal, scope change (new data type, new integration), incidents, adverse monitoring signals, and offboarding. ¹

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

1) Stand up the system of record (inventory + ownership)

• Create/normalize a third-party inventory: legal name, service description, business owner, IT owner (if different), contract owner, renewal date, systems touched, data categories, integration type, geographic footprint (as relevant), subcontractor dependence (if known). ¹
• Assign a TPRM control owner and define RACI across Procurement, InfoSec, Privacy, Legal, and the business. ²

Operator tip: if Procurement can onboard a supplier without your inventory entry, you do not control scope. Put an intake gate in the purchasing workflow.

2) Define a prioritization/tiering model you can defend

Create a tiering rubric that is easy to apply and produces consistent outcomes:

• Inherent risk inputs: data sensitivity, privileged access, external connectivity, customer impact, operational criticality, regulated processing, ability to disrupt core services, and concentration/single-point-of-failure. ¹
• Tier output: e.g., Critical / High / Medium / Low (labels are your choice). Record the tier and the rationale. ¹

Minimum bar: “prioritized” in GV.SC-07 means you can show that higher-risk third parties receive deeper assessment, tighter contract terms, and more frequent monitoring than lower-risk parties. ¹

3) Perform due diligence proportional to the tier

Build a standard due diligence package and vary depth by tier:

• All tiers: basic security questionnaire, confirmation of incident notification expectations, confirmation of subcontractor use for core services. ¹
• Higher tiers: request independent assurance artifacts (for example, third-party audit reports), review security policies, evaluate access control and SDLC practices if software is involved, and validate disaster recovery expectations appropriate to the service. ¹

Operational rule: if the third party cannot provide evidence, record the gap and treat it as risk. GV.SC-07 cares that you assessed and responded, not that every supplier is perfect. ¹

4) Record risk formally (risk register entries tied to the third party)

For each in-scope third party, document:

• Inherent risk tier, assessment date, assessor, artifacts reviewed
• Identified control gaps (with severity), compensating controls (yours or theirs), residual risk rating
• Decision: approve, approve with conditions, exception, or reject
• Required remediation and due dates with accountable owner (supplier owner or internal) ¹

This is the “understood, recorded, assessed, responded to” spine of GV.SC-07. ¹

5) Execute risk responses (contract, technical, and governance actions)

Common risk response actions you should operationalize:

• Contractual: security addendum, audit/assessment rights, incident notification timelines (define your expectation), subcontractor controls, data handling and return/destruction, minimum security requirements, right to terminate for cause. ¹
• Technical: least-privilege access, SSO/MFA requirements, network segmentation, API key management, logging requirements, conditional access, data loss controls for transfers. ¹
• Governance: formal risk acceptance with named approver when remediation is not feasible pre-go-live; document why the business accepted the residual risk. ¹

6) Monitor over the course of the relationship (not just at renewal)

Define monitoring methods and triggers:

• Time/event triggers: contract renewal, annual reassessment for top tiers (your policy decides cadence), significant scope change, material incidents, negative external security signals, or ownership changes. ¹
• Operational monitoring: track SLA breaches, incident tickets, access reviews for active accounts, and proof of completed remediation commitments. ¹

Practical control: maintain a “third-party risk actions” queue and review it in a recurring governance forum with Procurement, Security, and the business.

7) Offboarding and termination controls

Close the loop:

• Confirm access removal, key rotation, data return/destruction, and downstream subcontractor notifications where applicable. ¹
• Update inventory status to terminated and retain the assessment/decision record for your retention period. ¹

Required evidence and artifacts to retain (audit-ready list)

Keep these artifacts in a central repository tied to the third-party record:

• Third-party inventory entry (with service scope and owners) ¹
• Tiering rubric and completed tiering result with rationale ¹
• Due diligence package: questionnaires, independent assurance artifacts received, review notes, meeting minutes, clarifications ¹
• Risk register entry: inherent risk, issues, residual risk, decision, approvals ¹
• Contract/security addendum and tracked security obligations ¹
• Exception/risk acceptance memos with approver and expiration/trigger for revisit ¹
• Monitoring evidence: reassessment records, remediation tracking, access reviews, incident communications, renewal review outcomes ¹
• Offboarding checklist evidence (access removal confirmation, data destruction attestations where applicable) ¹

If you use Daydream or another GRC tool, configure it so evidence collection is recurring and tied to the control owner, which supports a defensible program posture. ²

Common exam/audit questions and hangups

Auditors and customer assessors tend to ask:

• “Show me your third-party inventory. How do you know it’s complete?” ¹
• “How do you decide who is high risk, and is the process consistent?” ¹
• “Pick two critical third parties. Show end-to-end evidence: assessment, decision, contract controls, and ongoing monitoring.” ¹
• “Where are exceptions documented? Who can accept risk, and how is it revisited?” ¹
• “How do you handle subcontractors/fourth parties for critical services?” ¹

Hangup to anticipate: teams can show onboarding questionnaires but cannot show monitoring, remediation closure, or re-assessment triggers. GV.SC-07 explicitly requires monitoring over the relationship. ¹

Frequent implementation mistakes (and how to avoid them)

1. Inventory is incomplete or stale.
   Fix: tie intake to Procurement and require an inventory record before contracting or PO issuance. ¹

2. Tiering is subjective (“high risk because it feels high”).
   Fix: publish a rubric with defined inputs and require rationale text. Calibrate quarterly using sample reviews. ¹

3. Assessment results don’t drive actions.
   Fix: require a risk response outcome for every meaningful gap: remediate, compensate, accept, or exit. Track to closure. ¹

4. Risk acceptance is informal.
   Fix: create a standard exception form with approver, scope, residual risk statement, and revisit trigger. ¹

5. Monitoring is only “renewal time.”
   Fix: add event-based triggers (incidents, scope changes) and operational monitoring (access reviews, SLA tracking) into the process. ¹

Enforcement context and risk implications (framework-aligned)

NIST CSF is a framework, not an enforcement regime. Your exposure typically shows up indirectly: customer security reviews, contractual noncompliance claims, insurer scrutiny after incidents, and regulator criticism under sector rules that require third-party risk controls. GV.SC-07 helps you demonstrate governance discipline and reduce supply chain attack paths by making third-party risk decisions explicit, tracked, and revisited. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Name the control owner, define RACI, and publish a short TPRM procedure mapped to GV.SC-07 outcomes. ²
• Build the minimum viable third-party inventory from Procurement/AP exports and IT lists; mark unknowns. ¹
• Define tiering rubric and approval workflow; pilot on a handful of key third parties. ¹

Days 31–60 (operate the workflow)

• Implement intake gating with Procurement and a simple questionnaire + artifact request set by tier. ¹
• Stand up the third-party risk register fields and exception template; require documented decisions. ¹
• Start remediation tracking for top-tier findings with due dates and owners. ¹

Days 61–90 (monitor and make it repeatable)

• Add monitoring triggers (renewal, scope change, incidents) and a recurring review meeting cadence for top tiers. ¹
• Test offboarding for one terminated third party and retain evidence (access removal, data handling closeout). ¹
• Automate recurring evidence collection in your GRC tool (Daydream or equivalent) to reduce manual chasing and improve audit readiness. ²

Frequently Asked Questions

Do we need to assess every third party the same way to meet GV.SC-07?

No. GV.SC-07 expects you to prioritize and assess proportionate to risk, then document the rationale and actions taken. Keep the tiering rubric and show that higher-risk third parties receive deeper diligence and monitoring. ¹

What counts as “recorded” for third-party risk?

A durable system of record: inventory entry plus a risk record that captures tier, assessment results, decision, approvals, and ongoing monitoring evidence. Email threads alone are hard to defend in audits. ¹

How do we handle fourth parties if we don’t have direct contracts with them?

Start by requiring disclosure of material subcontractors for critical services, then treat that as an input to your risk assessment and contract terms with the primary third party. Document what you asked for and what you received. ¹

What if a critical supplier refuses to provide security evidence?

Record the refusal as a gap, decide on a risk response (compensating controls, contractual changes, executive risk acceptance, or alternate supplier), and document the approval. GV.SC-07 is about assessment and response discipline. ¹

Who should be allowed to accept residual third-party risk?

Define a risk acceptance authority matrix tied to tier and impact, and require written approval with a revisit trigger. Keep the approval with the third-party record. ¹

How do we prove we “monitor over the course of the relationship”?

Keep evidence of scheduled reassessments for top tiers, event-driven reviews (incidents, scope changes), remediation closure, and operational checks like access reviews and SLA tracking tied to the third-party record. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes