Vendor Offboarding: Reducing Risk and Ensuring Compliance
A comprehensive guide to vendor offboarding covering triggers and planning, DORA exit strategy compliance, GDPR data return and deletion, access revocation, credential rotation, and post-offboarding verification procedures.
- 1
Plan vendor offboarding from the point of onboarding by embedding exit strategies, data handling obligations, and transition rights into every vendor contract.
- 2
DORA Article 28(8) requires operable, periodically tested exit strategies for ICT services supporting critical or important functions — documented plans alone are insufficient.
- 3
Exercise GDPR Article 28(3)(g) rights by requesting data return followed by certified deletion, and verify compliance through a written attestation from the vendor.
- 4
Revoke all vendor access within 24 hours of the offboarding effective date and rotate any shared secrets or credentials the vendor may have had visibility into.
- 5
Maintain a 90-day post-offboarding monitoring period to detect residual access, incomplete data deletion, or overlooked integration points.
Offboarding Triggers and Planning
Vendor offboarding can be triggered by a range of events: contract expiration, breach of contractual terms, deterioration of the vendor's security posture, strategic sourcing decisions, regulatory concerns, or the vendor's own business discontinuity. Regardless of the trigger, the offboarding process must be planned and executed with the same rigour applied to onboarding. Unstructured or ad hoc offboarding is one of the most common sources of residual third-party risk — orphaned access credentials, unreturned data, and lingering integrations create exploitable attack surfaces long after the business relationship has nominally ended.
Effective offboarding planning begins at onboarding. Every vendor contract should include explicit termination provisions that define notice periods, transition responsibilities, data handling obligations upon termination, and cooperation requirements during the wind-down period. DORA Article 28(8) requires financial entities to have exit strategies for ICT services supporting critical or important functions, and these strategies must be operable — not just documented. An exit strategy that has never been tested or rehearsed provides false assurance.
When an offboarding is initiated, assemble a cross-functional offboarding team comprising representatives from the business unit, IT, information security, legal, compliance, and procurement. Develop a detailed offboarding plan with task assignments, timelines, dependencies, and verification checkpoints. The plan should be proportionate to the vendor's risk classification — a critical ICT provider offboarding warrants a multi-week structured transition, while a low-risk vendor may be offboarded within days using a simplified checklist.
DORA Article 28(8) requires that exit strategies for critical or important ICT services be developed, tested, and reviewed periodically. An exit strategy that exists only on paper and has never been exercised will not withstand regulatory scrutiny.
DORA Exit Strategy Requirements (Article 28)
DORA places significant emphasis on exit planning as a core component of ICT third-party risk management. Article 28(8) requires financial entities to put in place exit strategies for ICT services supporting critical or important functions, taking into account risks that may emerge at the level of the ICT third-party service provider, including possible deterioration of the provider's services, failure, or disruption. These exit strategies must ensure that the financial entity can withdraw from contractual arrangements without undue disruption to its business activities, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services to clients.
The exit strategy must include, at minimum, an identification of alternative solutions or transitional arrangements, a defined transition period that allows for the orderly transfer of services, and arrangements to ensure data portability and continued access to data during and after the transition. Financial entities must also ensure that the exit strategy addresses scenarios where termination is not voluntary — for example, where a vendor becomes insolvent, suffers a catastrophic security breach, or is subject to sanctions that prevent continued engagement.
Practically, this means organisations must maintain a current assessment of alternative providers for each critical ICT service, have documented and periodically tested migration runbooks, and ensure that contractual terms grant them the rights necessary to execute the exit strategy — including rights to access, retrieve, and transfer data in standard formats, and to receive cooperation from the outgoing provider during the transition period. The Regulatory Technical Standards supplementing DORA provide further detail on the minimum content and testing cadence for exit plans.
Data Return and Deletion Under GDPR
When a vendor relationship ends, the handling of personal data becomes a critical compliance obligation. GDPR Article 28(3)(g) requires that the processor, at the choice of the controller, deletes or returns all personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data. This obligation must be explicitly addressed in the DPA and operationalised through the offboarding process.
Before requesting deletion, conduct a comprehensive data inventory to identify all personal data held by the vendor, including data in production systems, backup systems, disaster recovery environments, log files, analytics platforms, and any sub-processor systems. Request a written data return plan from the vendor that specifies the format, transfer mechanism, timeline, and verification method for returned data. For large data sets, agree on secure transfer protocols (encrypted SFTP, dedicated secure channels) and validate the integrity of returned data through checksums or sample verification.
Once data return is confirmed, issue a formal deletion request and require the vendor to provide a certificate of deletion — a written attestation, signed by an authorised representative, confirming that all personal data (including copies, backups, and derived data) has been permanently and irreversibly destroyed. Be aware that some vendors may claim legitimate retention requirements under Union or Member State law; these claims should be verified by your legal team. Track the deletion request, follow up if the certificate is not provided within the agreed timeframe, and retain the certificate as evidence of GDPR compliance.
GDPR Article 28(3)(g) gives the controller the choice between data return and deletion. In practice, most organisations request both — return of data followed by deletion with a written certificate. Ensure your DPA explicitly grants this right and specifies the timeframe for compliance.
Access Revocation and Credential Rotation
Access revocation is the most time-sensitive element of vendor offboarding. Every credential, API key, certificate, VPN configuration, and system account associated with the departing vendor must be identified, revoked, and verified as non-functional within a defined timeframe — ideally within 24 hours of the offboarding effective date for critical integrations. Delayed or incomplete access revocation is a leading cause of post-termination security incidents involving former vendors.
Begin with a complete access inventory derived from your identity governance platform, access management logs, and integration documentation. This inventory should cover all access types: user accounts (named and shared), service accounts, API keys and tokens, SSH keys, VPN credentials, physical access badges, and any temporary or emergency access grants that may not be captured in standard provisioning systems. For each access item, identify the system owner responsible for executing the revocation and document the revocation method.
After revoking vendor-specific credentials, rotate any shared secrets, encryption keys, or credentials that the vendor may have had visibility into during the engagement. This includes shared database passwords, API keys for third-party services that were accessible to the vendor, and any certificates where the vendor held the private key or participated in the key generation process. Credential rotation should extend to service accounts that were shared with the vendor's systems, even if the vendor no longer has direct access to those accounts. Verify all revocations by attempting to authenticate with the revoked credentials and confirming that access is denied.
Maintain a pre-built access revocation checklist for each vendor as part of your vendor register. Compiling the access inventory at offboarding time is slow and error-prone; maintaining it continuously as part of the ongoing relationship ensures rapid, complete revocation when needed.
Post-Offboarding Monitoring and Verification
The offboarding process does not conclude when the final credential is revoked. A structured post-offboarding monitoring period is essential to verify that all access has been effectively terminated, that no data residues remain with the former vendor, and that the organisation's operations continue without disruption after the transition. Establish a monitoring period of at least 90 days following the offboarding effective date.
During this period, actively monitor your security information and event management (SIEM) system for any authentication attempts originating from the former vendor's known IP ranges, user agents, or credential patterns. Monitor data loss prevention (DLP) systems for any unexpected data flows to the former vendor's domains or infrastructure. Review network flow logs for residual connections to the vendor's endpoints that may indicate overlooked integrations. Any anomalous activity detected during this period should be investigated immediately as a potential indicator of compromise or incomplete offboarding.
At the conclusion of the monitoring period, conduct a formal offboarding closure review. Verify that the data deletion certificate has been received and filed, that all access revocations have been confirmed, that shared credentials have been rotated, that the vendor's record in the management register has been updated to reflect the terminated status, and that lessons learned from the offboarding have been captured for process improvement. This closure review should be documented and approved by the business owner, information security, and compliance functions, creating a defensible record that the offboarding was executed thoroughly and in accordance with regulatory requirements.
What should an organisation do if a vendor refuses to provide a data deletion certificate?
If a vendor refuses to provide a deletion certificate, this constitutes a potential breach of the Data Processing Agreement under GDPR Article 28. Escalate the matter to your legal team and data protection officer. Issue a formal written demand citing the specific DPA clause and GDPR Article 28(3)(g) obligation. If the vendor continues to refuse, document the refusal, assess the risk of continued data retention, and consider filing a complaint with the relevant supervisory authority. In parallel, evaluate whether the vendor's refusal indicates a broader compliance failure that should be reported as part of your ongoing risk management activities.
How often should DORA exit strategies be tested?
DORA does not prescribe a specific testing frequency, but the Regulatory Technical Standards on ICT third-party risk management indicate that exit plans should be reviewed and, where appropriate, tested periodically. Industry best practice for critical ICT providers is to conduct a tabletop exercise of the exit strategy at least annually and a more comprehensive operational test every two to three years. The test should validate that alternative solutions remain viable, that migration runbooks are current, that data portability mechanisms function correctly, and that the organisation can maintain regulatory compliance and service continuity throughout the transition period.
What is the difference between access revocation and credential rotation during offboarding?
Access revocation is the act of disabling or deleting the specific accounts, keys, and credentials that were assigned to the departing vendor. Credential rotation is the separate act of changing shared secrets, passwords, API keys, and encryption keys that the vendor may have had access to or knowledge of during the engagement, even if those credentials were not directly assigned to the vendor. Both are necessary during offboarding. Revocation alone is insufficient if the vendor had visibility into shared credentials that remain unchanged — those credentials become a potential lateral access vector.
How should offboarding be handled when the vendor is acquired by another company?
A vendor acquisition is a significant trigger event that may require offboarding or re-onboarding depending on the circumstances. Under GDPR, a change of processor entity may require a new or amended DPA. Under DORA, a change in the provider's ownership or control structure is a material change that must be assessed for its impact on the ICT risk profile. Evaluate whether the acquiring entity meets your security and compliance requirements, whether data sovereignty commitments (particularly EU data residency) are maintained, and whether contractual terms transfer validly to the successor entity. If the acquiring entity does not meet your requirements, initiate a formal offboarding and transition to an alternative provider.
Vendor Onboarding Best Practices: Security and Compliance
13 min · DORA, GDPR, NIS2
ImplementationVendor Lifecycle Management: From Onboarding to Offboarding
14 min · NIS2, DORA, GDPR
ImplementationVendor Due Diligence: A Step-by-Step Guide
13 min · DORA, NIS2, GDPR
ReferenceDORA Third-Party ICT Provider Oversight
15 min · DORA
ReferenceGDPR Data Processing Agreements: A Complete Guide
12 min · GDPR
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.