Vendor Offboarding

The vendor offboarding requirement is to run a defined, repeatable exit process that (1) revokes the vendor’s access, (2) returns or destroys your data (including PHI), and (3) obtains confirmation that PHI was disposed of as required. Your job is to make offboarding provable: every access path closed, every integration removed, and every data disposition documented ¹.

Key takeaways:

• Offboarding must cover access revocation, integration removal, and PHI return/destruction confirmation ¹.
• Treat “offboarding” as a workflow with owners, triggers, and evidence, not a one-time email to IT.
• The hardest exam issue is proof: retain disposal attestations, access removal logs, and a final offboarding sign-off packet.

Vendor offboarding fails in predictable ways: accounts remain active “just in case,” API tokens never get rotated, and copies of PHI linger in backups or support tools long after the contract ends. HICP Practice 10.7 sets a simple bar, but it is operationally demanding: you must define vendor offboarding procedures that include access revocation, data return or destruction, and confirmation of PHI disposal ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to convert it into (1) clear triggers (what events start offboarding), (2) a system-by-system deprovision plan (what gets shut off and how you prove it), (3) a data disposition playbook (what data is returned, what is destroyed, and what “destroyed” means), and (4) a standardized evidence packet you can hand to auditors without rebuilding the story.

This page gives you requirement-level guidance you can deploy immediately: step-by-step actions, decision points, artifacts to retain, and the exam questions that commonly expose weak offboarding controls.

Regulatory text

HICP Practice 10.7: “Define vendor offboarding procedures including access revocation, data return or destruction, and confirmation of PHI disposal.” ¹

What the operator must do: You need written procedures that are actually executable across IT, Security, Privacy, Procurement, and the business owner. Those procedures must, at minimum:

• Revoke access the vendor had to your environment (accounts, VPN, SSO, shared mailboxes, privileged access, break-glass paths).
• Return or destroy data held by the vendor (including PHI and derived data sets).
• Confirm PHI disposal through contractual confirmation, attestation, certificate of destruction, or other written confirmation appropriate to the service ¹.

Plain-English interpretation (what “good” looks like)

A “good” vendor offboarding program produces a final offboarding packet that answers three questions without debate:

1. Can the vendor still get in? You can show they cannot.
2. Does the vendor still have our PHI? You can show it was returned or destroyed.
3. Did we verify disposal? You can show written confirmation tied to the contract and the specific data involved ¹.

Who it applies to

Entity scope

• Healthcare Organizations (providers, payers, clearinghouses, and their supporting entities).
• Health IT Vendors that handle PHI or provide systems that integrate with PHI workflows ¹.

Operational scope (where this shows up)

Apply this requirement to any vendor relationship where the third party:

• Stores, processes, transmits, or can access PHI.
• Has network connectivity, SSO access, admin accounts, or remote support access.
• Uses integrations (EHR interfaces, APIs, SFTP, HL7 feeds, service accounts, OAuth tokens).
• Holds data in non-obvious places (ticketing systems, call recordings, support chat logs, analytics exports).

A practical rule: if the vendor ever touched PHI or had a credential into your environment, they need a formal offboarding record.

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

Step 1: Define offboarding triggers and ownership

Create explicit triggers so offboarding happens even if the relationship ends abruptly:

• Contract termination (planned or for cause)
• Vendor acquisition, bankruptcy, or service shutdown
• Product migration or replacement
• Material security event involving the vendor
• End of a pilot that touched PHI

Assign owners:

• Business owner: confirms services ended, validates data return needs.
• IT/Security: executes access removal, integration shutdown, credential rotation.
• Privacy/Compliance: confirms PHI disposition requirements and documentation.
• Procurement/Vendor Management: coordinates contractual notices and deliverables.

Deliverable: an offboarding RACI and a single “offboarding request” intake form.

Step 2: Build an access revocation checklist (by access path)

Offboarding breaks when teams only disable one account and miss the rest. Build a checklist that forces enumeration:

Identity and accounts

• Disable vendor users in SSO/IAM.
• Remove vendor groups/roles.
• Disable local accounts created outside SSO.
• Revoke MFA factors issued to vendor personnel.

Privileged access

• Remove privileged roles and PAM entitlements.
• Expire standing access and delete emergency accounts used by vendor.
• Rotate any shared admin passwords the vendor could have known.

Network and remote access

• Disable VPN accounts and site-to-site tunnels.
• Remove allowlists for vendor IP ranges if they were vendor-specific.
• Disable remote support tools or vendor support portals.

Secrets and tokens

• Revoke API keys, OAuth client secrets, refresh tokens.
• Rotate service account credentials tied to vendor integrations.
• Remove SSH keys and certificates used for connectivity.

Evidence to capture: screenshots or exports from IAM/PAM showing disabled accounts, ticket references, and change records.

Step 3: Remove vendor integrations safely (don’t break production)

Integration removal is both a security and continuity problem. Use a controlled approach:

• Inventory integrations tied to the vendor: APIs, HL7 interfaces, SFTP jobs, webhook endpoints, ETL pipelines, database links.
• Identify downstream dependencies and data flows.
• Disable in a planned window when needed.
• Validate logs show no further inbound/outbound connections from vendor endpoints.

One common mistake is leaving a “temporary” integration running during transition and never coming back to close it. Require a documented exception with an owner and an end condition.

Step 4: Execute data return or destruction (PHI-first)

HICP explicitly calls for “data return or destruction” and “confirmation of PHI disposal” ¹. Operationalize that with a data disposition playbook:

1. Define the data set: what PHI the vendor received or generated; include derived data, logs, and support artifacts.
2. Choose disposition:
   • Return: vendor provides export in agreed format; you validate completeness.
   • Destroy: vendor deletes active data, replicas, and vendor-controlled copies; you require written confirmation.
3. Address retention: if the vendor claims legal or contractual retention, document what is retained, why, for how long, and how access is restricted. Tie it back to the contract terms and your risk acceptance.

Evidence to capture: export manifests, transfer confirmation, destruction attestation or certificate, and written confirmation specific to PHI.

Step 5: Obtain contractual confirmation of PHI disposal

Do not accept a generic “we deleted your data” email if PHI is involved. Ask for a written attestation that:

• Identifies the systems/locations covered (production, test, support, backups under vendor control).
• States the action taken (return or destruction).
• Confirms PHI disposal per contractual requirements ¹.

Your Procurement/Vendor Management function should standardize this language in contract templates and BAAs where appropriate, then enforce it at exit.

Step 6: Finalize an offboarding packet and close-out sign-off

Create a single packet that includes:

• Offboarding request and trigger event
• Access revocation evidence
• Integration removal evidence
• Data return/destruction evidence
• PHI disposal confirmation
• Residual risk exceptions (if any) with approvals
• Final sign-off by business owner, IT/Security, and Compliance/Privacy

If you use a platform like Daydream to manage third-party risk, make the offboarding packet a required workflow outcome: closure cannot happen until evidence fields are complete and approvals are logged.

Required evidence and artifacts to retain

Retain artifacts in a system of record (GRC tool or controlled repository) mapped to the vendor and the offboarding event:

• Offboarding procedure (current approved version) ¹
• Termination notice / contract end documentation
• Access revocation tickets and IAM/PAM exports
• Change records for integration shutdown and secret rotation
• Data inventory excerpt for the vendor relationship (PHI scope)
• Data return manifests or secure transfer confirmations
• Destruction attestation/certificate and PHI disposal confirmation ¹
• Final offboarding sign-off record and exception approvals

Common exam/audit questions and hangups

Auditors and assessors tend to press on proof and completeness:

• “Show me the procedure and the last few completed offboardings that followed it.”
• “How do you know all vendor access paths were removed, including non-SSO accounts and API tokens?”
• “What evidence confirms PHI disposal, not just account disablement?” ¹
• “How do you handle vendor-held backups or support tickets containing PHI?”
• “Who approves exceptions when a vendor cannot immediately destroy data?”

Hangup pattern: the organization can describe what they intended to do, but cannot produce artifacts that show what happened.

Frequent implementation mistakes (and how to avoid them)

1. Offboarding is owned only by IT. Fix: require Compliance/Privacy sign-off when PHI is in scope ¹.
2. SSO disablement is treated as complete deprovisioning. Fix: maintain an “access path register” that includes tokens, service accounts, VPN, and support tools.
3. No integration inventory. Fix: make integration mapping part of onboarding, then reuse it at offboarding.
4. Generic disposal language. Fix: require written confirmation that explicitly addresses PHI disposal and the systems covered ¹.
5. Offboarding doesn’t happen after “soft” exits. Fix: triggers must include pilots, migrations, and relationship dormancy, not just contract termination.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, weak offboarding increases the chance of unauthorized access after termination, lingering PHI exposure in vendor systems, and disputed responsibility during incidents. Your risk is highest where vendors had persistent connectivity, privileged access, or broad data replication.

Practical 30/60/90-day execution plan

To stay compliant without waiting on a long program buildout, execute in phases.

First 30 days (stabilize and make it repeatable)

• Publish a one-page offboarding standard that includes the three HICP elements: access revocation, data return/destruction, PHI disposal confirmation ¹.
• Stand up an offboarding intake process (ticket/workflow) with required fields: vendor name, systems, PHI scope, termination date, business owner.
• Draft the PHI disposal attestation template Procurement will send at termination.
• Pilot the checklist on one recent offboarding (or a current termination).

Next 60 days (close gaps and improve coverage)

• Build the access path register: IAM, PAM, VPN, remote support, API gateway, EHR interfaces, SFTP, certificates.
• Add “integration removal/secret rotation” as mandatory steps for vendors with technical connectivity.
• Train business owners and Procurement on triggers and deliverables.
• Start producing standardized offboarding packets in your system of record (Daydream or equivalent).

By 90 days (make it auditable)

• Require offboarding packet completion before vendor status changes to “terminated/closed.”
• Implement exception handling with approvals for any retained data or delayed destruction.
• Run an internal spot check: select a set of terminated vendors and verify no active accounts/tokens remain, and PHI disposal confirmations are present ¹.

Frequently Asked Questions

Do we need to offboard vendors that never handled PHI?

Apply the full HICP 10.7 process when PHI is involved, because PHI disposal confirmation is explicit in the requirement ¹. For non-PHI vendors, you still want access revocation and integration cleanup, but the PHI disposal evidence will not apply.

What counts as “confirmation of PHI disposal”?

Written confirmation from the vendor tied to your contract requirements that PHI was returned or destroyed, and that the disposal covered the relevant systems and locations under the vendor’s control ¹. Keep it with the offboarding packet.

If we disable SSO, do we still need to rotate API keys and service account credentials?

Yes. SSO disablement does not revoke API keys, OAuth secrets, SSH keys, or embedded credentials used by integrations. Treat credential rotation and token revocation as separate offboarding tasks tied to integration removal.

How do we offboard a vendor when we are switching to a replacement and need overlap?

Document a time-bound exception that states what access remains, why it is required, and who owns the risk. Keep the exception with the offboarding record, and complete full revocation and PHI disposition at the end of overlap ¹.

What if the vendor says they cannot delete data from backups?

Escalate to Procurement and Privacy/Compliance. Document what is retained, the reason, the vendor’s controls restricting access, and the plan for eventual disposal or expiration, then record an approved exception and keep the vendor’s written position in the offboarding packet.

What evidence is most persuasive in an audit?

A closed offboarding workflow with (1) IAM/PAM deprovision proof, (2) change records showing integrations disabled and secrets rotated, and (3) a PHI return/destruction attestation that is specific to your data ¹.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices