Learn how to manage supplier offboarding, develop exit plans, coordinate secure data return and deletion, revoke third-party access and assess concentration and fourth-party dependencies. Includes a practical supplier migration exercise.
Imagine you are a GRC analyst working at Meridian Financial Services, a fictional UK fintech company.
Meridian has decided to replace the cloud provider hosting its customer-facing application.
The existing contract ends in sixty days. The new supplier has offered a more competitive service, and the Technology Director expects the transition to proceed without major disruption.
During your initial review, you discover:
The Technology Director asks:
"Can we complete the migration and close the old supplier's risk assessment when its contract expires?"
Not necessarily.
The contract's expiry date does not prove that services have been migrated successfully, information has been handled appropriately, supplier access has been revoked or outstanding obligations have been satisfied.
You also need to consider whether the replacement introduces new risks, including increased dependency on shared infrastructure.
This is why supplier offboarding and exit planning are important parts of Third-Party Risk Management (TPRM).
In this guide, you will learn how to plan a controlled supplier exit, identify important security and operational risks, manage data and access, evaluate concentration risk and document an evidence-based exit recommendation.
Supplier offboarding is the coordinated process of ending or changing a third-party relationship while managing the associated security, operational, contractual and information risks.
Depending on the relationship, offboarding may involve:
The process should be proportionate to the supplier's service, criticality and risk exposure.
For example, ending a stationery supply agreement may require limited security activity.
Replacing a production cloud provider supporting payment processing is likely to require substantial coordination and testing.
Procurement may coordinate contract termination, but other functions may own important exit activities.
Technical teams may need to migrate systems and revoke access. Privacy specialists may need to confirm data-handling arrangements. Business owners must assess continuity and service impacts.
GRC helps connect these activities to the supplier's risk assessment, maintain visibility of unresolved exposure and support appropriate governance decisions.
Poorly managed supplier exits can introduce or increase risks.
Examples include:
| Risk category | Example consequence |
|---|---|
| Confidentiality | Former supplier retains unnecessary access to sensitive customer information |
| Integrity | Data becomes corrupted during migration |
| Availability | A critical service is interrupted because the replacement is not ready |
| Data protection | Personal data is retained or handled contrary to applicable requirements |
| Security | Old API credentials remain active after termination |
| Contractual | Important transition obligations are not completed |
| Operational | Essential knowledge or configurations are lost |
| Concentration | Replacement increases dependence on a shared infrastructure provider |
These risks can continue after the original contract ends.
An organisation may be exposed through retained information, residual access or incomplete service transitions.
A supplier relationship should not be treated as securely closed merely because the commercial agreement has expired.
A common mistake is to consider supplier exit only when the organisation decides to terminate a relationship.
For important suppliers, exit planning should begin before the relationship is approved.
This is particularly important when the supplier:
These questions help establish whether the supplier relationship creates unacceptable dependency or lock-in.
An exit plan does not necessarily require a fully implemented replacement service from day one.
However, it should contain enough information to support a realistic response if the relationship must end.
There are two broad exit situations.
A planned exit may occur because:
A planned exit generally allows greater opportunity for controlled migration, testing and coordinated access termination.
An emergency exit may be triggered by:
Emergency exits may involve incomplete information, limited transition assistance and urgent decisions.
A planned exit may allow detailed data migration and testing before cutover.
An emergency exit may require prioritising critical business services, activating continuity arrangements and making risk-based decisions with incomplete information.
Both require governance, but their urgency and practical options differ.
A useful supplier exit plan can follow eight stages.
Establish exactly what is ending.
Consider:
Some organisations use a supplier for multiple services.
Terminating one service may not end the entire relationship.
The business or service owner should remain accountable for the business consequences of the transition.
Other stakeholders may include:
Assign specific responsibilities rather than listing a department without naming a delivery owner.
Retrieve:
Some risks may increase during transition.
For example, temporary access granted to migration engineers could increase privileged-access exposure.
Determine what will replace the current service.
Possible outcomes include:
Do not assume that a replacement supplier is secure simply because it offers equivalent functionality.
The replacement may require its own criticality assessment, inherent risk review, due diligence and approval.
Define:
Plan information return or deletion, credential changes and removal of supplier permissions.
These activities require technical coordination.
Collect evidence that the required activities have been completed satisfactorily.
Document the final status, unresolved matters, authorised decisions and records retained for future reference.
This creates an auditable record of the exit.
Information handling is often one of the most important parts of supplier offboarding.
Before termination, establish:
The organisation may require information to be exported in a structured and usable format.
For example, customer records stored in a SaaS platform may need to be extracted into a format supported by the replacement system.
Confirm:
A successful file transfer does not necessarily mean the new system is ready.
The migration team may need to verify that records remain complete, that applications can use them and that relevant business processes work.
For important services, testing should reflect the consequences of failure.
After information has been returned or transferred, the supplier may need to delete remaining copies according to the contract and applicable law.
This can include information in production systems, archives and relevant subcontractor environments.
Where the supplier acts as a processor for a UK GDPR controller, Article 28(3)(g) requires contractual terms addressing the return or deletion of personal data at the controller's choice after services end, together with deletion of existing copies unless UK law requires storage.
Backup deletion may need practical arrangements that account for retention cycles and safeguards. The ICO recognises that immediate deletion from certain backups may not always be practicable, provided appropriate protections and deletion arrangements are in place.
These obligations should be reviewed with Privacy and Legal, and the current applicable rules should be checked when managing a real exit.
A supplier might send an email stating:
All customer data has been deleted.
Is that sufficient?
The answer depends on the relationship, requirements and assurance needed.
For material information exposure, the analyst should determine what the statement covers.
Useful questions include:
Evidence might include a formally authorised deletion confirmation, a documented exit report or other proportionate assurance.
The organisation should avoid requiring sensitive technical evidence that is unnecessary for the purpose.
Data returned: The customer has received the required information.
Data validated: The returned information has been checked for completeness and usability.
Data deleted: Relevant copies have been removed in accordance with applicable requirements.
Data retained under an exception: Certain information remains subject to a documented lawful or contractual basis and appropriate safeguards.
These are different outcomes.
A successful export does not prove deletion, and a deletion confirmation does not prove that the exported data is usable.
A former supplier may retain access through several mechanisms.
Examples include:
Simply disabling a supplier's named employee accounts may not remove every access path.
First, identify relevant access and integration dependencies.
Second, determine the correct revocation sequence to avoid disrupting a service that has not yet been migrated.
Third, coordinate approved access removal or credential rotation.
Fourth, verify that access is no longer available.
Fifth, record the evidence and update relevant asset, identity and supplier records.
Meridian removes CloudCore's named administrator accounts but overlooks a service integration using an API key.
The integration remains active after termination.
This creates unresolved exposure.
The correct action is to identify the key's purpose, coordinate its safe revocation or rotation and verify the outcome without causing unintended business disruption.
Access termination is complete when relevant access paths have been addressed and verified, not merely when an offboarding ticket is marked complete.
Replacing a supplier can introduce operational risk even if the new provider has stronger security controls.
Consider a production system migration.
Potential problems include:
For critical services, transition planning should include measurable success criteria and appropriate fallback arrangements.
Before cutover, Meridian may require:
These criteria should be agreed by the relevant owners before the migration begins.
GRC may review the risk position and governance evidence, but technical testing should be performed by suitably qualified personnel.
Supplier concentration risk arises when an organisation depends heavily on one supplier, a small group of suppliers or shared underlying dependencies, creating the possibility of widespread impact from a common failure.
This can occur even when each supplier has passed its individual security assessment.
An organisation relies on a single provider for several essential services.
For example, one cloud provider hosts its production payment platform, customer portal and internal operations systems.
A major outage could affect all three.
Several different suppliers rely on the same underlying provider.
For example:
Although the suppliers are different legal entities, they may all use the same cloud provider or region.
A disruption affecting that shared infrastructure could affect several services simultaneously.
An organisation may not have a direct contract with the common underlying provider.
The dependency may exist through subcontractors, making it harder to identify.
Important services may depend on infrastructure or operations concentrated in the same geographic area.
Examples include shared data centre regions or locations exposed to common physical hazards.
Concentration risk requires assessment of the actual dependency and potential failure scenarios, not simply counting supplier names.
A GRC analyst can start with the supplier inventory and business service mapping.
Determine which organisational activities are critical.
Record the suppliers supporting each service.
Determine which underlying infrastructure or providers are relevant.
Look for common hosting providers, regions, subcontractors or other single points of failure.
Consider what could happen if the shared provider or dependency were unavailable.
Determine whether alternatives, recovery strategies or segregation meaningfully reduce the exposure.
Possible responses may include diversification, improved continuity arrangements, alternative service capabilities or formally accepted residual exposure.
Meridian uses three SaaS providers:
| Supplier | Business service | Underlying dependency |
|---|---|---|
| PayMetrics | Payment analytics | Cloud provider X, Region A |
| SupportBridge | Customer support | Cloud provider X, Region A |
| VerifyNow | Identity verification | Cloud provider X, Region A |
Each supplier may have completed satisfactory individual due diligence.
However, a major disruption in Region A could affect all three services.
The concentration risk should be recorded and evaluated at the business service or enterprise level, rather than assuming the three individual assessments fully capture the common exposure.
Not necessarily.
Switching suppliers may be expensive and could introduce different risks.
The organisation should assess the potential consequences, available resilience arrangements, feasibility of alternative regions or providers and cost of treatment.
The correct decision depends on the business context and approved risk appetite.
Concentration risk is closely related to supplier substitutability.
A supplier may be difficult to replace because of:
CloudCore hosts Meridian's production platform using proprietary services and configurations.
Migrating to another provider may require application changes, infrastructure redesign and substantial testing.
Even if several alternative hosting companies exist, the relationship may not be quickly substitutable.
A GRC analyst should distinguish the existence of alternative providers from the organisation's practical ability to transition.
Depending on feasibility, the organisation may:
These actions may reduce the consequences of supplier failure without requiring immediate replacement.
Meridian decides to migrate its production customer platform from CloudCore to NovaHost, a fictional replacement provider.
The contract ends in sixty days.
Business dependency: The existing platform supports essential customer services.
Data: CloudCore stores customer account information and application data.
Access: The supplier has privileged administrative access and service integrations.
Migration: Application export has been completed but not fully validated.
New supplier: NovaHost has not completed security due diligence.
Concentration: Two existing Meridian suppliers already rely on NovaHost's underlying cloud region.
The analyst should coordinate with the relevant business and technical owners to establish the required risk and assurance activities.
| Action | Accountable function | Evidence or outcome |
|---|---|---|
| Confirm exit scope and service dependencies | Business owner | Approved exit scope |
| Complete NovaHost due diligence | GRC and Security, with business owner | Documented assessment and decision |
| Validate exported customer information | Migration team | Integrity and completeness results |
| Test replacement service | Technology and Operations | Acceptance test results |
| Review shared infrastructure exposure | GRC and resilience specialists | Concentration risk assessment |
| Confirm contractual data exit obligations | Legal and Privacy | Agreed data handling requirements |
| Plan credential revocation | IAM and Infrastructure | Approved access termination plan |
| Validate continuity and fallback | Business Continuity and Technology | Tested or appropriately assessed arrangements |
| Verify data return and deletion | Supplier owner, Privacy and GRC | Relevant evidence and exceptions |
| Approve final exit closure | Designated authority | Signed-off closure record |
CloudCore's planned termination presents material service continuity, information security and supplier concentration risks. I recommend that the exit remain subject to a coordinated transition plan, completion of NovaHost's risk assessment, validation of customer data migration, and verification of access removal and relevant data-handling obligations. The shared infrastructure dependencies should also be evaluated before final migration approval. The current supplier assessment should not be marked fully closed while material exit activities remain unresolved.
This recommendation is evidence-based and identifies the governance decisions required.
A supplier exit should have defined completion criteria.
Examples include:
Some obligations may continue after termination.
For example, a contractual retention requirement or dispute may require records to be maintained for an authorised period.
This does not necessarily prevent closing every operational exit task, but outstanding obligations must remain visible and assigned.
If the organisation knowingly retains a material unresolved exposure, it may require a separate authorised risk decision.
Closing the supplier's operational relationship should not silently close the associated risk record.
The closure record should state what was completed, what remains open and who is responsible for the remaining exposure.
An exit report should allow management to understand the final position.
Supplier: CloudCore Infrastructure
Service: Production customer application hosting
Reason for exit: Planned migration to replacement provider
Business owner: Head of Infrastructure
Exit status: In progress
Completed activities:
Outstanding activities:
Material risk: Incomplete transition and overlapping infrastructure dependencies may affect service availability and information security.
Recommendation: Continue the controlled transition and withhold final exit closure pending defined verification activities.
Decision required: Business and technical approval of migration readiness and subsequent authorised exit closure.
A final report should preserve references to supporting evidence rather than repeating every detailed technical record.
You are a junior GRC analyst at Meridian Financial Services.
The organisation is terminating its relationship with DataBridge Analytics, a fictional SaaS supplier.
The provider processes customer transaction information and supports monthly management reporting.
Its contract expires in forty-five days.
Prepare a supplier exit assessment containing:
Material risks: Potential loss or corruption of transaction analytics during migration, continued access through API credentials, incomplete deletion or retention assurance, unassessed replacement supplier exposure and increased reliance on shared infrastructure.
Exit plan: Establish an accountable business owner, complete replacement supplier due diligence, test migration, agree access termination sequencing, confirm relevant contractual data obligations and verify closure evidence.
Data validation: Confirm completeness, accuracy and usability of the exported transaction records in the replacement platform.
Access controls: Inventory and revoke remaining supplier API credentials when safe to do so, and verify the results.
Data handling: Obtain proportionate confirmation of return, deletion and any documented retention exceptions, including relevant backup and subcontractor considerations.
Concentration: Assess the potential impact of a failure affecting the infrastructure shared by multiple suppliers.
Recommendation: Do not mark the exit fully closed based solely on contract expiry. Complete or appropriately disposition material transition requirements and obtain the designated approvals.
| Criterion | Marks |
|---|---|
| Risk identification and scenario quality | 20 |
| Exit planning and ownership | 20 |
| Data and access safeguards | 20 |
| Concentration risk assessment | 15 |
| Verification and closure criteria | 15 |
| Management recommendation | 10 |
| Total | 100 |
A strong response should clearly distinguish completed tasks, unverified activities, current exposures and proposed actions.
Important dependencies and data portability issues should be considered earlier.
Credentials, data and subcontractor access may remain.
Exported information must be validated for completeness and usability where relevant.
Supplier access extends beyond named employee accounts.
Retention, technical arrangements and applicable law require appropriate review.
The replacement introduces its own risks and dependencies.
Multiple individually approved suppliers can create concentration risk.
Completion statements should be evaluated against the defined closure criteria.
The analyst supports risk assessment and governance, while technical execution remains with the assigned specialists.
Acceptance does not remove an underlying exposure or substitute for required controls.
Before closing the exit, confirm:
Supplier offboarding is a risk management process, not simply an administrative contract termination.
Important exits may require data migration, access revocation, information return or deletion, business continuity planning and verification.
Exit planning should begin early for critical or difficult-to-replace suppliers.
A replacement supplier should undergo proportionate assessment before the organisation relies on it.
Concentration risk can arise through both direct supplier relationships and shared fourth-party dependencies.
GRC analysts support exit planning by identifying exposures, coordinating assurance, documenting unresolved matters and preparing defensible recommendations.
A supplier exit is successful when the organisation has managed the material security and business risks of the transition, not merely when the contract has ended.
Next lesson: How to Prepare a Third-Party Risk Assessment Report
You have now covered the major stages of the third-party relationship lifecycle, from initial supplier assessment through to monitoring and exit.
The next lesson brings those activities together and focuses on a practical GRC skill: preparing a clear, evidence-based third-party risk assessment report for business owners, senior management and authorised risk decision-makers.