GV.SC-10 Supplier offboarding: requirements and evidence

What GV.SC-10 supplier offboarding asks when a supplier contract ends

GV.SC-10 expects supply chain risk management plans to cover what happens after a partnership or service agreement ends. If a supplier is leaving, or an auditor or customer asks how your organization handles exits, the question is whether an exit plan exists and whether it was written before the relationship ended. Offboarding is a supply chain risk because the relationship's end is when several exposures appear at once: the supplier still holds credentials and network paths, it still holds your data, and the product or service you depend on may no longer receive updates. The Core covers this under the Cybersecurity Supply Chain Risk Management (GV.SC) Category in the GOVERN Function, which means it belongs in your program design, not only in the procurement team's closing checklist.

The first risk is lingering access. Service accounts, API keys, VPN profiles, federated sign-ons and shared administrator logins often outlive the contract because nobody owns the list of what the supplier was given. The second is data left with the supplier, including copies in backups, support tickets, sandboxes and logs that no one remembered to request back or destroy. The third is unsupported products: a platform or component that the supplier stops maintaining can keep running in your environment without patches. The fourth is an exit forced by an adverse event, such as a breach at the supplier or a sudden insolvency, where there is no time to negotiate. Offboarding is often the least-planned phase of the supplier life cycle because the contract's focus is on starting the service. Confirm with your own contract owners whether exit terms, data return timelines and access revocation duties are written into current agreements, since that gap determines how much work an exit becomes.

Which suppliers, access paths and data fall under supplier offboarding

Before any exit plan can be written, the organization has to decide what the offboarding covers. These four decisions set the size of the work, and each one starts from the supplier ranking the organization already maintains under GV.SC-04, so the highest-criticality relationships receive the most thorough exit steps.

Which supplier relationships count

Start with the supplier record from GV.SC-04 and decide which relationships trigger a full offboarding: critical suppliers, shared providers that serve several internal systems, cloud providers, and managed service providers that administer infrastructure on your behalf. A low-criticality supplier may need only a checklist, while a managed service provider with administrative rights needs a full transition. Record the tier for each relationship so the exit plan matches the risk. Confirm that the register is current, since a relationship missing from it will not get an exit plan.

Which access paths must be revoked

A supplier rarely holds one account. Inventory every route in: named user accounts, API keys and service tokens, VPN profiles, SSO federation trusts, shared mailboxes, and remote support sessions. Federated access is easy to miss because removing the supplier's identity at the provider may leave a trust or group membership in place at your side. Map each path to its owner and revocation step, and check that the revocation is confirmed at the target system, not only in the contract paperwork.

Which data sits with the supplier

Data leaves a supplier in more places than the primary service. Check backups, bulk exports, log archives, support tickets, analytics copies, and test datasets that may hold production records. Decide for each store whether it is returned to you, deleted with written confirmation, or retained for a stated legal reason. Ask the supplier for a list of locations rather than relying on a general statement that data will be deleted, and record who verifies the deletion.

Which products reach end of life

A supplier exit can also expose products your systems still run after the vendor stops support. Identify hardware, firmware, software versions and appliances tied to the relationship and note their end-of-life dates, support contracts and known vulnerabilities. Decide whether each product will be upgraded, replaced, isolated or kept under a documented exception. Products that continue to run without vendor patches should appear in the risk register with an owner, rather than disappearing once the contract ends.

How an assessor tests supplier offboarding

This table walks through the steps an assessor typically takes to test GV.SC-10, the evidence each step requests and the findings that most often appear. Read it as a sampling exercise: the assessor starts with the written procedure, then picks terminated suppliers and follows each one through access removal and data disposal. The main takeaway is that a procedure on paper does not pass the test unless each sampled supplier leaves a traceable record.

Test step	Evidence requested	Common findings
Review the documented offboarding procedure	Written supplier termination procedure, roles named for each exit task, and approval steps for ending a supplier relationship	Procedure covers contract expiry only and omits early termination, insolvency or breach scenarios
Confirm exit plans exist for critical suppliers	Transition or exit plan per critical supplier, with named replacement sources, data migration steps and a review date	Plans are generic templates with no supplier-specific steps, or no plan exists for suppliers rated critical
Check end-of-life and obsolescence planning is tied to the relationship	Records linking a supplier's end-of-life or support end date to the affected services and to the offboarding or replacement plan	End-of-life dates tracked in asset registers but never linked to the supplier record or a replacement decision
Select a sample of terminated suppliers	List of suppliers whose relationship ended in the review period, drawn from contract or procurement records	Terminated suppliers missing from the sample source because they are not flagged in the supplier register
Trace each sampled supplier to access removal	Identity provider or directory logs showing accounts, API keys and shared credentials disabled, with dates compared to contract end	Access still active after contract end, shared service accounts never rotated, or no timestamp to compare against the end date
Trace each sampled supplier to data return or disposal	Return or deletion certificates, vendor confirmation of disposal, and asset records for devices or media that held the organization's data	No record of data disposal, or confirmation covers only some of the systems the supplier held data in
Check deprovisioning across connected systems	Access review or certification records showing supplier identities were removed from all target applications, not only the primary one	Supplier accounts removed from the directory but still present in downstream applications or cloud tenants
Verify ownership and sign-off	Closure checklist signed by the business owner and the security or procurement function	Offboarding closed without sign-off, or the business owner never received the closure task

How to implement supplier offboarding step by step

This sequence turns GV.SC-10 into a repeatable exit process for each critical supplier, so the organization can show that plans, access removal and data return were defined before a relationship ended and were carried out when it did.

Define exit triggers and an accountable owner
Start by listing the events that start an offboarding: contract expiry, termination for cause, a supplier acquisition, a product reaching end of life, or a decision to move the service in-house or to another provider. Assign one accountable owner for each supplier, usually the business owner with a named security and procurement counterpart. Record the trigger list and owner assignments in the supplier register that supports GV.SC-04, so exits are not started informally. The output is an approved trigger list and an owner per critical supplier, which shows an assessor that offboarding is governed rather than improvised.
Write a termination and transition plan per critical supplier
For each critical supplier, write a plan covering how the service stops, how it moves to a replacement or back in-house, who makes the cutover decisions, which contract clauses apply, and what happens if the supplier exits suddenly. Include a dependency inventory drawn from the asset records under ID.AM, so the team knows which systems, interfaces and data flows depend on the supplier. Ask legal to confirm notice periods and survival clauses in writing. The output is a signed plan per critical supplier, stored with the contract file.
Set end-of-life and obsolescence checkpoints
Where a supplier provides software, hardware or a managed component, set checkpoints that trigger before the vendor stops support. Review the vendor's published end-of-life dates, track patch and support status in the asset inventory, and decide early whether to upgrade, replace or accept residual risk with documented approval. Connect each checkpoint to the risk register so unsupported components are visible to leadership. The output is a dated checkpoint schedule and a record of decisions for every component approaching end of support.
Build the access removal runbook and its timing
Write a runbook that lists every account, API key, certificate, VPN profile, federated application, network allowance and shared credential the supplier holds, and the person who removes each one. Specify the order: revoke new access first, then disable existing accounts, then rotate shared secrets the supplier knew. Automate removal where the identity platform supports it, for example by using provisioning that deprovisions users when their application access ends, and confirm the exact behavior with the vendor's documentation before relying on it. Tie removal to the exit date and record who confirmed each item. The output is the runbook and a completed removal log with timestamps, which is the evidence most assessors ask to see.
Define data return or disposal with verification
Agree in writing which data the supplier must return and which it must destroy, in what format, by what method and within what period set by the contract. Require a certificate or written confirmation of disposal, and cover backups, subprocessors and copies held by the supplier's own staff. Where data is returned, check integrity and completeness on the organization's side before the supplier copy is deleted. Confirm the disposal method against the organization's own data handling standard. The output is a data return or disposal record with the verification step, the signed confirmation and the date each item was closed.
Rehearse exits for critical suppliers
Run a tabletop exercise for each critical supplier that tests a sudden exit, such as the supplier failing, being acquired or losing a certification. Walk through the transition plan, the access runbook and the data recovery steps, and record gaps as improvement items under ID.IM. Repeat the exercise when the plan or the dependency inventory changes. The output is an exercise report, a list of findings with owners and a closure record, which shows that the plan works under pressure and not only on paper.
Record outputs and close each offboarding
Keep one offboarding file per supplier that holds the trigger record, transition plan, checkpoint decisions, removal log, data disposal certificate and exercise findings. Close the file only when every item is evidenced and the owner signs off, then update the supplier register to show the relationship has ended. Review closed files during the supplier monitoring cycle under GV.SC-07 to find recurring gaps. The output is a complete, dated offboarding record per supplier that can be produced to an assessor or to a customer asking how supplier exits are handled.

What meeting supplier offboarding costs in money and effort

This table compares the cost components of ending a supplier relationship cleanly, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote and to decide which parts to build in-house. No figures are given here, so confirm every price and duration with the vendor or partner before budgeting.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring	Commercial identity governance or lifecycle licenses priced per user, connector or environment, plus any exit tooling the supplier requires	Confirm license terms and exit clauses; self-hosted open-source identity tools can remove per-seat license spend, though operating them still costs staff time
Engineering time for access removal automation	One-time build, then recurring upkeep	Number of target applications, whether SCIM or other provisioning is supported, and how many systems lack automated deprovisioning	Start with the most critical suppliers and applications; confirm which connectors the chosen tools provide before scoping the build
Legal and procurement effort for exit clauses	One-time per contract, recurring at renewal	Contract count, criticality tier, and how many suppliers lack termination assistance or data return terms	Standardize exit language in templates by criticality so renewals do not require fresh negotiation
Transition and exit exercises	Recurring, usually scheduled	Complexity of the service, number of internal teams involved, and whether the supplier must support a live handover	Test exit plans on a sample of critical suppliers rather than every supplier each cycle, and record lessons learned
Data return and disposal verification	Recurring per exit event	Volume and location of data held by the supplier, and whether certified deletion or destruction evidence is required	Ask suppliers for written disposal certificates in the contract and reuse a single checklist across exits
Evidence upkeep	Recurring	Number of offboarding events, depth of logs kept for access removal, and retention periods set by policy or regulation	Generate evidence from existing identity and ticketing logs so records are produced as a by-product of the process
External review and auditor sampling	Recurring, tied to audit cycle	Scope of the assessment, how many offboarding events the auditor samples, and whether the auditor requires extra walkthroughs	Keep a consistent evidence index so sampled events can be produced quickly; ask the auditor to confirm sample sizes before fieldwork

Which offboarding evidence passes an assessment

An assessor testing GV.SC-10 looks for proof that a supplier exit was planned, executed and closed out, not a policy that says it should be. The cards below cover six artifacts that together show the relationship ended in an orderly way. Each one works best when it is attached to the supplier record at termination rather than assembled before an audit.

Supplier exit or transition plan

This is the plan written before or at the end of a critical supplier relationship. It names the reasons for exit, the replacement or insourcing path, the service continuity steps and the people who approve each step. Assessors check that the plan covers both normal and adverse terminations, such as a supplier failing or a contract being cut short. Keep the approved version on the supplier record and date every revision, so the plan in the file is the one the team actually followed.

End-of-life and obsolescence register

This register lists the products, platforms and services the departing supplier provided, with their support end dates and the planned replacement for each. It shows that the organization knew what it would lose when the relationship ended and had a path for each item. Review it when the contract end date is set and again at termination, and record who accepted any residual risk from components with no remaining vendor support.

Access removal record

This record shows when each supplier identity, account, API key, VPN profile and group membership was disabled or deleted, measured against the contract end date. Assessors compare the timestamps with the termination date and look for gaps, such as accounts still active weeks later. Pull the record from the identity provider logs and directory audit trail rather than from a manual checklist, and confirm that shared or service accounts were rotated as well.

Data return or disposal confirmation

This is the written confirmation that the supplier returned or securely destroyed the organization's data, along with any hardware that held it. The confirmation should name the data sets, the method (return, deletion or destruction), the date and the person who verified it. Where the supplier kept copies for legal or regulatory reasons, record the basis and the retention end date. Ask for this confirmation in the exit terms before the contract ends, since suppliers have less incentive to provide it afterward.

Periodic access certification results

Access certification campaigns show that reviewers checked supplier-linked access on a schedule and revoked anything no longer needed. The results list each access item, the reviewer decision (keep, change or revoke) and the deadline for that decision. For GV.SC-10, the useful evidence is a campaign that caught supplier access still open after an exit or a contract change. Run the campaign on a fixed cycle and keep each completed round as a dated record.

Exit review meeting minutes

Minutes from the post-exit review record what was planned, what happened, which access and data steps were verified and which issues remain open. They show that someone with authority reviewed the close-out and accepted any exceptions. Assessors look for named owners, dated action items and follow-up on lessons learned. Schedule the review before the contract formally ends, and file the minutes against the supplier record with the other five artifacts so the full set can be produced in one place.

How self-hosted open-source tools produce offboarding evidence

Open-source identity tools can produce much of the evidence an assessor will ask for when a supplier leaves, but none of them satisfies GV.SC-10 by itself. The organization still owns the decision to end the relationship, the transition plan and the data return or disposal record. What the tools contribute is a traceable trail showing that the supplier's access was reviewed and removed. Start by listing every system where supplier identities hold accounts, groups or roles, then decide which of these tools will be the system of record for each. midPoint is the most direct fit for the review step. Its access certification campaigns assign designated reviewers, who must decide within a set timeframe whether to keep, change or revoke each access item, such as a role assignment. Run a campaign scoped to the supplier's identities and roles at the point of termination, and retain the campaign outcomes as evidence that access was reviewed rather than simply left in place. This also counters access accumulation, where a supplier keeps permissions gathered over several engagements. Confirm the review timeframe, reviewer assignment and reporting options against the midPoint documentation for your release, since the campaign design determines what the record can prove. Licensed under EUPL-1.2+.

authentik's SCIM provider handles the propagation step. It pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target once they lose access to the application. For offboarding, the key check is that removing a supplier from the source group in authentik leads to deprovisioning in each connected application, and that the sync results are logged. Test this in a non-production environment with a dummy supplier account, and record the time between removal and deprovisioning. Note that a full sync every hour sets a ceiling on how stale a target can be, so decide whether that window is acceptable for the supplier's criticality. Licensed under MIT. FreeIPA, built on 389 Directory Server, gives you a central directory for users, groups, hosts and other network objects, with centralized access control and delegated administration through its web UI and command line tools. Delegated administration lets you separate who can disable a supplier account from who approves the change, which supports the accountability that auditors look for. Confirm how FreeIPA's audit and administrative logs are retained and exported to your evidence store. Licensed under GPL-3.0-or-later. None of these tools handles the return or disposal of supplier-held data, the end-of-life or transition planning, or the decision to terminate. Those artifacts, along with the signed closure record, must come from your contract and offboarding process. Confirm with your assessor how logs and reports from all three tools will be combined into one offboarding evidence package.

Who owns supplier offboarding: your team, a partner and the auditor

Your organization owns GV.SC-10. Only you can decide when a supplier relationship ends, whether that is a planned exit, a termination for cause or a supplier failure, and only you can judge whether the transition plan protects the services and data that depended on that supplier. The control expects the exit to be planned in advance, so the decision, the business owner and the timeline belong with the people accountable for the relationship, not with the technical team that carries out the removal.

Exit decision and ownership: Name the business owner who approves termination, transition or end-of-life replacement, and record the reason for the exit.
Transition and end-of-life plans: Approve who takes over the service, how continuity is maintained and what happens to open incidents and commitments.
Access removal sign-off: Confirm that supplier accounts, API keys, certificates and network paths were disabled, and record the date and the person who confirmed it.
Data return or disposal confirmation: Obtain written confirmation from the supplier that your data was returned or destroyed, and decide whether any retention is legally required.
Lessons and records: Keep the offboarding record with the contract file so that later reviewers can see who decided what.

Before relying on this split, confirm that your contracts already give you rights to data return, certified destruction and exit assistance.

Questions buyers ask about supplier offboarding and GV.SC-10

What does GV.SC-10 require in practice?

GV.SC-10 expects your supply chain risk management plans to cover what happens after a supplier partnership or service agreement ends. In practice, that means a documented way to end critical relationships in both normal and adverse conditions, a plan for end-of-life and obsolescence, prompt removal of the supplier's access to your systems, and a process to return or dispose of any assets that hold your data. It also means managing the risk of data leakage at termination. The outcome is stated in CSF 2.0 Subcategory language, so an assessor will look for a written procedure, records that it was followed, and proof that access and data were actually removed. Confirm the exact wording and the seven Implementation Examples in the NIST CSF 2.0 Reference Tool before you build your checklist.

Is GV.SC-10 mandatory?

For most organizations, no. NIST states that the Cybersecurity Framework is voluntary and that it is not a regulatory agency. The exception is U.S. federal agencies, which were required to use the framework under a 2017 executive order. Many organizations still adopt GV.SC-10 because a customer or supplier contract requires it, or because a regulator or sector body builds on the framework. Check your contracts and any sector rules that apply to you. If a customer asks for alignment, the request will usually name the offboarding evidence it expects, so ask for that list in writing.

How long does supplier offboarding work take, and what drives the effort?

No duration is fixed by NIST, so the effort depends on your environment. The main drivers are the number of suppliers with access, how many systems and accounts each one touches, whether access is granted through a central identity provider or through local accounts, how much data the supplier holds and where, and whether the exit has to be planned or happens under pressure. Suppliers that host data or run integrations usually take the most effort. Ask any implementation partner for a written scope that lists the systems, identity sources and data stores in scope, and the deliverables that will be produced at the end.

What does the work need from our team?

Offboarding touches several functions, so the work needs named owners from each one. Procurement and legal own the contract exit clauses and the return or destruction terms. Security and IT operations own access removal and the verification that it happened. Application owners know which integrations and data flows must stop. Data protection or compliance staff decide what must be returned, retained or deleted. Your team also needs an accurate supplier inventory and access records, because you cannot remove what you have not listed. Plan time for these people to review the procedure and sign off on evidence.

Can one person handle supplier offboarding in-house?

One capable person can run a single, simple offboarding in-house if the supplier has limited access and the systems are documented. It becomes harder when many suppliers exit, when access is spread across several identity stores, or when the procedure must be repeatable and evidenced for an assessor. A useful test is whether your team can name every account a supplier holds, remove them within your own timeline, and prove the removal with logs or records. If that proof is hard to produce, a second person or an outside partner may be worth considering. Identity tooling such as the authentik SCIM provider can automate deprovisioning for applications it manages, but you still need to confirm coverage for each target system.

What does a fixed-scope DeployOpen engagement cover for supplier offboarding?

DeployOpen works on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts. For offboarding, that scope can cover implementing or configuring self-hosted open-source platforms that support access removal and evidence, such as identity lifecycle tooling, access certification campaigns or directory services, along with documenting the offboarding procedure and the evidence it produces. Ongoing support and testing are available as retainers. DeployOpen does not issue audit reports or certifications, and it does not set your supplier contract terms. Your written scope should list each system in the boundary and each deliverable, so you can check what is included before you sign.

Can a consultant certify that we comply with GV.SC-10?

No. NIST does not offer certifications or endorsements of CSF-related implementations or services, and it has no plans for a conformity assessment program. A consultant can help you prepare systems, procedures and evidence, but only an independent assessor, auditor or certification body issues a report or attestation. Your organization owns its controls and decides how to demonstrate alignment. When you engage anyone to help, ask them to state in writing that they prepare evidence and do not issue assurance, and ask your customer which independent report, if any, they will accept.

How DeployOpen scopes and prepares supplier offboarding evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so supplier offboarding can be built into the systems and records that show it happened. We prepare the access removal, data return or disposal and transition evidence that your organization owns and that an independent assessor reviews.

How we scope

Agree in writing which supplier relationships, systems and accounts fall within the offboarding scope before work starts.
Inventory the supplier identities, groups, API keys and integrations that need deprovisioning at termination.
Record which datasets, backups and devices hold your data and must be returned, disposed of or certified as destroyed.

How we build

Configure automated deprovisioning so supplier accounts are removed from target applications when access ends, and test that removal.
Set up access certification reviews so designated reviewers confirm or revoke remaining supplier access on a schedule you set.
Document the transition and end-of-life steps, including the decision points for critical suppliers, in runbooks your team can execute.

How we hand over

Deliver a written record of the offboarding procedure, configuration settings, test results and access review outputs.
Provide an evidence pack mapped to GV.SC-10 and related controls, so your assessor can trace each claim to a log or record.
Walk your team through operating the runbooks, leaving ownership of controls and evidence with your organization.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
Retest offboarding paths after platform upgrades or changes to supplier integrations, and update the documentation to match.
Confirm with your independent auditor or certification body which evidence they expect, since only they issue reports or certificates.

GV.SC-10 Supplier offboarding