Vendor Offloading and Data Termination Playbook

Lead
This playbook covers the four things that have to happen when a vendor relationship ends: access revoked, data returned or verifiably deleted, contract closed, and residual risk assessed. It is for vendor management, IT security, and compliance teams to run when a vendor relationship ends, whether through contract expiration, performance issues, or a change in strategy. Following this playbook reduces the risk of lingering access, orphaned data, and compliance gaps that could lead to breaches or regulatory penalties.

<!-- meta description: A practical vendor offboarding and data termination playbook that guides security and compliance teams through access revocation, data deletion verification, contract closure, and risk assessment. -->

Prerequisites (Checklist)

• Current vendor inventory record with all associated systems, data classifications, and access points documented
• Signed vendor contract or agreement available for review (including data handling, retention, and termination clauses)
• Access to identity and access management (IAM) systems, privileged access management (PAM) tools, and application-specific admin consoles
• Data classification matrix showing what types of data the vendor processed or stored
• Legal or procurement contact for contract closure and final invoicing
• Security operations (SecOps) or incident response team notified of impending offboarding (if high-risk vendor)
• Communication plan template for internal stakeholders (e.g., business owners, IT service desk)

Phase 1: Preparation and Notification

1. Gather vendor dossier
   Pull the vendor record from the TPRM system, including:

   • Legal entity name, DUNS, and contract ID
   • List of all systems, applications, and data repositories the vendor accessed
   • Data classification levels (e.g., confidential, PII, PHI, financial)
   • Access types (e.g., privileged user, service account, API key, physical access)
     Rationale: A complete inventory prevents missed access points and ensures all data touchpoints are addressed.

2. Review termination clauses
   Examine the vendor contract for:

   • Required notice period
   • Data return or deletion timelines and formats
   • Certification or attestation requirements (e.g., SOC 2, ISO 27001)
   • Liability for residual data
     Rationale: Contractual obligations drive the timeline and verification steps; missing them can result in disputes or non-compliance penalties.

3. Initiate formal offboarding notice
   Send a written notice to the vendor per contract terms, copying legal, procurement, and the business owner. Include:

   • Effective termination date
   • Request for data return/deletion plan within 5 business days
   • Point of contact for coordination
     Rationale: Early notice gives the vendor time to prepare and sets clear expectations.

4. Schedule internal kickoff
   Convene a meeting with IT security, IAM, application owners, and the business stakeholder to:

   • Assign owners for each system/application
   • Confirm verification methods (e.g., logs, screenshots, certification)
   • Set target completion date (typically 30 days from notice)
     Rationale: Coordinated effort avoids siloed work and ensures accountability.

Phase 2: Access Revocation (Days 1-10)

5. Disable interactive user accounts
   For each system/application:

   • Identify all vendor user accounts (including service accounts)
   • Disable login ability immediately (do not delete yet)
   • Document disablement timestamp and ticket number
     Decision point: If any account shows login activity after disablement, investigate for compromised credentials → escalate to SecOps.

6. Revoke federated access and API keys

   • Remove vendor from identity provider (IdP) groups or role mappings
   • Delete or rotate API keys, OAuth tokens, and service-account credentials
   • Confirm revocation via IdP logs or API-gateway reports
     Rationale: Federated access and API keys are often overlooked; they provide persistent backdoors if not revoked.

7. Terminate privileged access

   • Check PAM solutions for vendor-owned privileged accounts
   • Check out and rotate passwords; then disable the accounts
   • Verify no active sessions via PAM session monitoring
     Rationale: Privileged accounts pose the highest risk; they must be neutralized before deletion.

8. Remove physical access (if applicable)

   • Collect badge, keys, and any hardware tokens
   • Disable building access in the physical security system
   • Return any vendor-owned equipment
     Rationale: Physical access can lead to data theft or plant malware; treat it with the same rigor as logical access.

Phase 3: Data Return or Deletion Verification (Days 5-20)

9. Receive vendor's data handling plan

   • Review the vendor's submitted plan for data return or deletion
   • Ensure it covers all data classifications identified in the dossier
   • Confirm format, transfer method, and certification (e.g., deletion certificate)
     Decision point: If the plan is incomplete or uses non-approved methods (e.g., unencrypted email), reject and request revision → escalate to legal if vendor refuses compliance.

10. Execute data return

    • If data is to be returned:
      • Receive data via encrypted transfer (SFTP, AS2, or encrypted physical media)
      • Perform integrity check (hash verification)
      • Scan for malware before storing in quarantine
      • Archive per retention policy or destroy if no longer needed
        Rationale: Secure transfer prevents interception; integrity checks ensure completeness.

11. Verify data deletion

    • If data is to be deleted:
      • Obtain a deletion certificate from the vendor detailing:
        • Data sets deleted, dates, and method (e.g., NIST 800-88 Clear/Purge/Destroy)
        • Third-party witness or audit log if required
      • Validate certificate against contractual requirements
      • For cloud services, review provider's deletion logs or request a deletion confirmation
        Rationale: Deletion without verifiable evidence leaves residual risk; certificates provide auditability.

12. Check for residual data

    • Search logs, backup systems, and shared repositories for any vendor-related data remnants
    • Review DLP alerts for exfiltration attempts during offboarding window
    • Conduct a quick scan of known data stores for vendor-specific identifiers
      Decision point: If residual data is found, initiate data-retention or deletion workflow → involve data governance team.

Phase 4: Contract Closure and Residual Risk Assessment (Days 15-30)

13. Finalize financial and contractual closure

    • Ensure all invoices are paid and final statements received
    • Obtain signed release of liability from vendor (if contract requires)
    • Archive contract and related documents in the contract management system
      Rationale: Financial closure prevents disputes; proper archiving supports future audits.

14. Update TPRM and risk registers

    • Mark vendor status as "Offboarded" in the TPRM tool
    • Remove vendor from active risk assessments and scorecards
    • Record offboarding date and any open issues (e.g., pending deletion certificate)
      Rationale: Keeping the inventory clean avoids inflated risk metrics and focuses efforts on active vendors.

15. Conduct residual risk review

    • Evaluate whether any risk remains due to:
      • Data potentially retained beyond agreed timelines
      • Access that could not be fully verified (e.g., legacy systems)
      • Ongoing obligations (e.g., audit rights survival clauses)
    • Document any residual risk and assign owner for monitoring or mitigation
      Rationale: Some risks survive termination; acknowledging them enables proactive monitoring.

16. Lessons learned and feedback

    • Hold a retrospective with stakeholders to identify:
      • What worked well (e.g., automated account disabling)
      • Gaps in the process (e.g., manual steps prone to error)
      • Updates needed to the playbook or vendor questionnaire
    • Archive retrospective notes and update the vendor offboarding checklist
      Rationale: Continuous improvement reduces effort and increases effectiveness over time.

Decision Points Summary

• Post-disable login activity → Investigate for credential compromise → Escalate to SecOps
• Inadequate vendor data plan → Request revision → Escalate to legal if non-compliant
• Residual data discovered → Initiate data retention/deletion workflow → Involve data governance

Escalation Path

• Access-related issues (unauthorized login, privileged access not revoked) → IT Security Manager → Director of Information Security → CISO
• Data-handling disputes (vendor refuses to delete or returns data improperly) → Legal Counsel → Chief Legal Officer
• Contractual or financial disagreements → Procurement Lead → Head of Procurement → CFO
• High-risk vendors (those handling critical data or privileged access) → Notify IT Security and Legal immediately upon any anomaly

Post-Completion Checklist

• All vendor user and service accounts disabled across all systems
• Federated access (IdP groups, API keys) revoked and confirmed via logs
• Privileged access rotated and disabled in PAM solutions
• Physical access credentials collected and disabled
• Data return received with integrity verification OR deletion certificate obtained and validated
• Residual data scan completed with no findings (or documented mitigation plan)
• Contract archived, final invoices paid, release of liability obtained
• TPRM updated: vendor status set to "Offboarded" with offboarding date recorded
• Residual risk assessment completed and any open risks assigned owners
• Lessons learned retrospective conducted and playbook updates logged

Related Playbooks and Templates

• Data Processing Agreement (DPA) Template for Vendor Onboarding. Covers the onboarding-side contractual controls that offboarding must reverse.
• Incident Response Runbook: Ransomware and Business Email Compromise. Activated if post-disable login activity suggests malicious use.
• Vendor Risk Assessment Questionnaire (Standard + Tiered versions). Updated during offboarding to reflect change in risk status.

---

Conclusion

The risk in vendor offboarding is what nobody closes: an API key still valid six months later, a backup copy of your customer data outside the deletion certificate's scope, a contract that auto-renewed because no one sent the termination notice. The four phases above (preparation, access revocation, data verification, and contract closure) exist to make each of those someone's explicit task with a date against it. Document what you did at each step. The audit trail is the only thing that answers the question a regulator asks later, which is not whether you offboarded the vendor but how you know their access is actually gone.

Key Takeaways & Next Steps

• Start with a solid inventory. A detailed dossier prevents forgotten accounts or data stores.
• Revoke every credential fast. Disable accounts first, then delete keys and physical badges before any data hand-off.
• Demand proof of data handling. Whether the vendor returns data or wipes it, get a signed certificate or verification log.
• Close the loop in contracts and risk registers. Archive the agreement, settle invoices, and mark the vendor as "Offboarded" in your TPRM system.
• Run a quick retrospective. Capture lessons learned and update the playbook so the next offboarding goes even smoother.

Action checklist:

1. Populate the vendor dossier in your TPRM tool today.
2. Schedule the internal kickoff meeting within the next two business days.
3. Draft the formal offboarding notice and send it to the vendor before the end of the week.
4. Assign owners for each access revocation task and track progress in your ticketing system.

Work through the list and the offboarding leaves a record: access closed, data accounted for, contract terminated on the date it was supposed to be.