GV.SC-10: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement

GV.SC-10 requires your cybersecurity supply chain risk management plan to spell out what happens after a third-party relationship ends: data return or destruction, access removal, asset recovery, ongoing confidentiality, and verification that offboarding actually occurred. To operationalize it, build a formal “third-party exit” playbook, contract clauses, and a repeatable evidence trail per termination event. ¹

Key takeaways:

• Define post-termination security steps (data, access, assets, and attestations) inside your SCRM plan, not ad hoc in email threads. ¹
• Connect plan requirements to contracts, a deprovisioning workflow, and evidence you can hand to an auditor. ²
• Treat “end of service” as a high-risk change event with owners, timelines, and verification steps. ¹

Third-party risk rarely ends on the contract end date. Access can persist, data can remain in backups, credentials can be forgotten in non-production environments, and hardware can sit in a cage with your configs. GV.SC-10 addresses that exact failure mode by pushing you to plan for the “after” phase: the set of security activities that must occur once a partnership or service agreement concludes. ¹

For a Compliance Officer, CCO, or GRC lead, the operational win is clarity: you need a documented exit process that is consistent across third parties, tailored by risk, triggered reliably, and evidenced. The point is not to create a perfect offboarding checklist; the point is to prevent residual access and uncontrolled data retention, and to prove you prevented it. ²

This page translates the gv.sc-10: cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement requirement into a control you can run: who owns it, what to build, what artifacts to retain, and how to avoid the audit traps that show up when offboarding is informal.

Regulatory text

Excerpt (GV.SC-10): “Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement.” ¹

Operator interpretation of the text: Your documented cybersecurity supply chain risk management (C-SCRM) plan must explicitly cover termination and transition activities, not just onboarding and ongoing monitoring. Auditors will look for (1) defined steps, (2) clear ownership, (3) contract hooks that make the steps enforceable, and (4) evidence that the steps happened for real third-party exits. ²

Plain-English interpretation (what the requirement means)

If a third party stops working with you, you must be able to answer, quickly and with proof:

• Where did our data go, and what did the third party keep?
• Who still has access (accounts, API keys, tokens, VPN, SaaS roles), and how do we know it’s removed?
• What assets do we need back (devices, certificates, logs, configs)?
• What obligations survive termination (confidentiality, breach notification, cooperation, subprocessor flow-down)?
• How do we verify completion and handle disputes? ¹

Who it applies to (entity and operational context)

Applies to: Any organization running a cybersecurity program that relies on third parties to store, process, transmit, or administer systems/data, including SaaS providers, MSPs/MSSPs, cloud platforms, consultants, contractors, and key partners. ¹

Most relevant operational contexts:

• Third parties with privileged access (admin consoles, remote support, code repositories)
• Third parties hosting regulated or sensitive data (customer data, employee data, source code, encryption keys)
• Service transitions (switching providers, M&A divestitures, outsourcing insource decisions)
• High-availability systems where “turn it off” is not possible without a cutover plan ²

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

1) Assign ownership and scope the “exit” control

• Control owner: Third-party risk management (TPRM) or GRC, with operational execution split across IT, Security Operations, IAM, Legal/Procurement, and the service owner.
• Scope definition: Decide which third parties must follow the full exit process (typically risk-tiered) and which can follow a lighter checklist (low-risk tools with no data and no access). ¹

2) Build a standard Third-Party Exit Plan (runbook)

Create a runbook that is short enough to be used and strict enough to be audited. Minimum sections:

• Trigger events: contract end, termination for cause, non-renewal, service migration, subprocessor removal.
• Access termination: identity accounts, SSO/SAML connections, API keys, certificates, IP allowlists, shared credentials, break-glass accounts, support portals.
• Data disposition: return format, secure transfer method, deletion requirements, backup/replication considerations, log retention alignment.
• Asset recovery: hardware return, destruction certificates, recovery of tokens/keys you own, removal of your agents from endpoints.
• Ongoing obligations: confidentiality survival, breach notification window alignment (if contractual), cooperation during investigations, litigation holds.
• Verification: what evidence is acceptable (attestation letter, ticket closure, screenshots, export logs, audit report references), who signs off. ²

3) Make it enforceable in contracts and purchase flows

Your plan will fail if the contract is silent. Work with Legal/Procurement to add or standardize clauses for:

• Data return and secure deletion (including subcontractors where applicable)
• Access removal and confirmation
• Assistance with transition (handover support, reasonable cooperation)
• Post-termination audit/attestation rights appropriate to risk
• Survival of confidentiality and security obligations ¹

Practical tip: add a “Termination Assistance + Data Disposition Exhibit” to your security addendum so it’s easy to include and easy to find during audits.

4) Implement a repeatable workflow that creates evidence automatically

Operationalize the runbook in your ticketing/GRC tooling:

• Initiate an “Exit Case” tied to the third party record.
• Tasks auto-generated by tier (IAM, Security, IT, Service Owner, Legal).
• Hard gates: do not close the case until required artifacts are attached and approvals captured.
• Exceptions: a controlled process for incomplete offboarding (e.g., bankruptcy, unresponsive provider), with compensating controls documented. ²

Daydream (as a natural fit): use it to map GV.SC-10 to a named control owner, embed the exit checklist as a procedure, and schedule recurring evidence collection so offboarding events don’t disappear from your audit trail. ²

5) Verify with independent signals, not only third-party attestations

Attestation letters help, but verification should include at least one internal confirmation where possible:

• IAM export showing account disablement/deletion
• SSO app disabled, tokens revoked, SCIM deprovision logs
• Network/VPN rules removed
• Cloud tenant access removed (role assignments, keys)
• CMDB or endpoint tooling confirming agent uninstall ¹

6) Close the loop: update inventories and downstream dependencies

• Update the third-party inventory to “terminated” with date and exit evidence link.
• Remove the third party from data flow diagrams, subprocessors list (if maintained), and access reviews scope.
• Confirm internal teams removed hardcoded endpoints, webhook URLs, and integrations. ¹

Required evidence and artifacts to retain

Maintain an “Exit Packet” per terminated third party (scaled by risk). Typical artifacts:

• Offboarding/exit ticket with timestamps, assignees, and approvals
• Access removal evidence (IAM logs/exports; SSO app disabled evidence; VPN revocation proof)
• Data return confirmation (file inventory, transfer confirmation) and deletion attestation (where required)
• Asset return receipts or destruction certificates (if applicable)
• Contract/security addendum clauses covering termination obligations
• Exceptions and compensating controls record (if exit incomplete) ²

Common exam/audit questions and hangups

Auditors and assessors tend to probe these areas:

• “Show me your SCRM plan section that covers termination.” (plan-level requirement) ¹
• “Pick three terminated third parties; show evidence that access was removed and data was disposed per contract.” (operating effectiveness)
• “How do you know shadow integrations are removed?” (integration inventory maturity)
• “What happens if a third party is acquired or your account team changes?” (owner continuity)
• “How do you ensure subprocessors also delete data?” (flow-down enforcement) ²

Hangup to anticipate: teams often can show a terminated contract but cannot show deprovisioning, data deletion proof, or a documented exception.

Frequent implementation mistakes (and how to avoid them)

1. Exit process exists only for IT vendors.
   Fix: scope all third parties with data/access, including consultants and agencies. ¹

2. Relying on “contract ended” as proof.
   Fix: require technical access revocation evidence and a closure sign-off. ²

3. Ignoring backups and replicas.
   Fix: define deletion expectations for backups in the data disposition language, even if deletion occurs at the next rotation cycle.

4. No owner for the last mile.
   Fix: name a service owner accountable for confirming integrations are removed and business data has been retrieved.

5. Exit is not triggered reliably.
   Fix: make Procurement/Accounts Payable events (non-renewal, PO closure) open an exit case automatically where possible. ²

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement. Practically, GV.SC-10 maps to common breach and operational failure patterns: residual third-party access, untracked data retention, and gaps during provider transitions. Those gaps increase incident response complexity and can create contractual, privacy, and customer-trust exposure. ¹

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Add a GV.SC-10 “post-termination activities” section to your C-SCRM plan and publish an exit runbook. ¹
• Identify your top-risk third parties (privileged access, sensitive data) and define the mandatory exit packet contents for them.
• Update template contract language or security addendum to include data disposition, access removal confirmation, and transition assistance. ²

Next 60 days (operationalize)

• Implement an exit workflow in your ticketing/GRC system with role-based tasks and closure criteria.
• Train Procurement, IT, Security, and service owners on triggers and responsibilities.
• Run tabletop offboarding on one real provider migration (or a simulated termination) and capture the evidence packet.

By 90 days (prove it works)

• Sample recently terminated third parties and backfill exit packets where possible; document exceptions explicitly.
• Add exit completion as a metric for TPRM reporting (qualitative status: on-time, late, exception).
• Operationalize recurring evidence: periodic checks for orphaned accounts, stale SSO apps, and lingering VPN rules tied to terminated third parties. ²

Frequently Asked Questions

Does GV.SC-10 require a data deletion certificate for every terminated third party?

The requirement is that your plan includes post-termination provisions; it doesn’t prescribe a single artifact. Define risk-based evidence standards, and require stronger proof for third parties that store or process sensitive data. ¹

What if the third party refuses to attest to deletion or won’t respond after termination?

Treat it as an exception with documented compensating controls (access already revoked, integrations removed, legal notice sent). Capture the attempts, decisions, and residual risk acceptance in your exit packet. ²

How do we handle SaaS offboarding where data persists in backups?

Put backup/replica handling in your data disposition terms and your exit runbook, including what “deletion” means and what confirmation is acceptable. Document what the provider can and cannot do and retain that record with the exit evidence. ¹

Are subcontractors (subprocessors) included in GV.SC-10?

GV.SC-10 is framed around supply chain risk management, so you should address flow-down where third parties use their own third parties. Contractually require the primary third party to ensure equivalent post-termination disposition for your data. ¹

Who should sign off that offboarding is complete?

Use a two-signature model: the service owner confirms business/data transition, and Security or IAM confirms access termination. If you centralize in TPRM, TPRM can provide final closure once both confirmations and artifacts are attached. ²

How do we operationalize this without slowing down Procurement?

Standardize termination clauses in templates and make the exit workflow lightweight for low-risk third parties. Reserve the heavier exit packet for high-risk relationships where residual access or data retention creates real exposure. ²

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes