Return of Assets

“Return of assets” is an offboarding control with two goals: prevent unauthorized retention of sensitive information and stop former users from keeping the means to access your environment. HITRUST CSF v11 02.h is explicit that the requirement applies to employees, contractors, and third-party users, and it lists categories that teams often miss, such as documents, software, access devices, and credentials ¹.

For a Compliance Officer, CCO, or GRC lead, this requirement is less about writing a policy and more about building a tight operational handshake between HR (or the business sponsor), IT asset management, Identity and Access Management (IAM), physical security, and third-party management. The control fails most often in the seams: a contractor “rolls off” without a formal termination ticket, a badge isn’t collected, a shared admin credential remains known, or a BYOD user keeps synced corporate files.

This page gives you requirement-level implementation guidance: who is in scope, what to do step-by-step, what evidence to retain, and how auditors test it. It also includes a practical execution plan you can run with immediately, without waiting for a major tooling project.

Regulatory text

HITRUST CSF v11 02.h requires: “All employees, contractors, and third-party users shall return all of the organization's assets in their possession upon termination of their employment, contract, or agreement. Assets including equipment, documents, software, access devices, and credentials shall be returned promptly.” ¹

Operator interpretation (what you must do):

1. Define “organizational assets” broadly enough to include physical items, information assets, and access enablers (credentials, tokens, badges).
2. Trigger an offboarding workflow whenever employment ends, a contract ends, or a third party’s access is no longer authorized.
3. Ensure assets are returned (or securely wiped/disabled where “return” is not practical), and record the outcome.
4. Close the loop with evidence: for each termination, show what was issued, what was recovered, and what was revoked.

Plain-English interpretation

If someone stops working for you, they should not keep your stuff or your access. “Stuff” includes laptops and phones, but also paper files, removable media, proprietary software, ID badges, hardware tokens, keys, and any credentials or authentication factors they had. “Promptly” means you should not allow an uncontrolled gap between termination and asset recovery; your process should reflect the risk of continued possession or access ¹.

Who it applies to (entity and operational context)

Entities: All organizations implementing HITRUST CSF controls ¹.

People in scope (do not narrow this to employees):

• Employees (full-time, part-time, temporary)
• Contractors and consultants (including staff augmentation)
• Third-party users (any external user with authorized access, including partner support, outsourced IT, revenue cycle, managed services, and implementation teams) ¹

Operational contexts where teams get burned:

• Remote offboarding (no onsite handoff)
• Third parties with “evergreen” access that outlives a statement of work
• Shared credentials and service accounts known by individuals
• BYOD and personally owned endpoints with corporate email/files
• Physical access assets (badges, keys) managed outside IT

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

1) Set the asset-return standard (policy + procedure)

• Policy statement: upon termination, all organizational assets must be returned and credentials/access devices surrendered; exceptions require documented approval ¹.
• Define asset categories: equipment, documents, software, access devices, credentials. Use the HITRUST list as your minimum set ¹.
• Define ownership for each category: IT Asset Management (devices), Physical Security (badges/keys), IAM (credentials/MFA), Business Data Owners (documents), Procurement/Third-Party Management (third-party-issued assets used for your work).

2) Build a single trigger for offboarding

You need a reliable event that starts the workflow:

• Employees: HR termination event.
• Contractors: contract end date plus sponsor-driven “roll-off” event.
• Third-party users: access removal request from the service owner or third-party manager.

Practical control: require that no account is created for a non-employee until a sponsor is assigned who also owns offboarding initiation. This prevents “orphaned” third-party accounts later.

3) Reconcile “what was issued” before you try to recover it

Asset return fails when you don’t know what to ask for. Maintain an issuance record that ties:

• Person (name, unique ID, employer if third party)
• Asset identifiers (serial number, badge number, token ID)
• Access methods (MFA factors, smartcards, VPN profiles)
• Date issued and current custodian

Minimum viable approach: a centralized asset register and an access register (IAM exports can serve as evidence for credentials). More mature: integrate HR/contractor roster with CMDB/ITAM.

4) Execute coordinated offboarding tasks

Use a termination checklist ticket with parallel task owners. Required task families mapped to HITRUST language ¹:

A. Equipment return

• Recover laptops, mobile devices, peripherals, removable media.
• For remote staff: ship kit with tracking; document receipt and condition.
• If the user cannot return (lost/stolen): document incident, disable device where possible, and record exception approval.

B. Documents and information assets

• Collect paper files, notebooks, printed PHI/PII, and any organization-provided storage media.
• Confirm return or secure destruction with an attestation where physical return is infeasible.

C. Software

• Remove/licensing reclaim steps for assigned software (especially locally installed tools tied to named users).
• For third parties: confirm removal of organization-provided software and configuration profiles, where applicable.

D. Access devices

• Recover badges, keys, smartcards, hardware tokens.
• If the badge/token cannot be recovered: disable it and document the disposition.

E. Credentials

• Disable accounts, revoke sessions/tokens, remove from groups, rotate shared secrets the individual knew, and recover MFA factors where they are “assets” (hardware token, smartcard).
• Treat shared admin credentials as the highest-risk gap; require rotation when a privileged user exits.

5) Close-out and certify completion

Require a formal close step:

• Offboarding ticket cannot close until each asset/access category is marked returned/revoked or exception approved with rationale.
• Collect the departing user’s signed acknowledgement (or sponsor attestation for third parties) that organizational assets were returned and no copies of documents or credentials are retained ¹.

6) Monitor for stragglers

Create a simple detective control:

• Periodic report of active accounts for terminated users (employee and non-employee) cross-checked against HR and contractor rosters.
• Open tickets for any mismatch and document remediation.

Required evidence and artifacts to retain

Auditors typically want to sample terminations and trace them end-to-end. Keep artifacts that make that easy:

Per termination (ideal evidence packet):

• Termination/offboarding ticket with timestamps and assigned owners
• Asset issuance record (what the person had)
• Proof of return: receiving log, shipping tracking, badge/token intake record, device check-in
• Proof of revocation: IAM screenshots/exports showing disablement, group removal, MFA revocation, VPN removal
• Exception documentation (lost device, non-return, legal hold) with approvals and compensating actions
• Departing user acknowledgement or sponsor attestation for third-party users ¹

Program-level evidence:

• Return of assets policy and offboarding procedure
• Role definitions (RACI) for offboarding tasks
• Templates: offboarding checklist, exception form, sponsor attestation
• Training/communications to managers and sponsors

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me three recent terminations and the evidence that assets, badges, and credentials were recovered or revoked.” ¹
• “How do you offboard contractors and third-party users when HR is not the system of record?” ¹
• “How do you ensure documents and software are included, not just hardware?” ¹
• “What happens when equipment is not returned?” Look for documented exceptions and compensating controls.
• “How do you handle privileged access on termination?” Rotation and revocation are the focal points.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating return of assets as an IT-only control.
   Fix: enforce shared ownership. Physical Security and business data owners must be on the checklist.

2. Mistake: No inventory baseline, so recovery is guesswork.
   Fix: tie issuance to identity. If you can’t say what was issued, you can’t prove it was returned.

3. Mistake: Contractor/third-party offboarding depends on someone “remembering.”
   Fix: require a sponsor and an end date; prompt sponsors to re-validate access and assets at renewal points.

4. Mistake: Credentials handled loosely (“account disabled eventually”).
   Fix: make credential revocation and shared secret rotation explicit checklist items, with evidence.

5. Mistake: Exceptions are informal.
   Fix: require a written exception with approvals and concrete compensating actions, then track closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes. Practically, failure of asset return creates direct exposure: retained devices and documents can lead to unauthorized disclosure, and retained credentials/access devices can enable post-termination access. HITRUST’s wording makes it clear that both physical assets and access enablers are in scope ¹.

Practical execution plan (30/60/90-day)

Use this as an operator’s rollout plan. Timelines are phases, not promises.

First 30 days: stabilize the minimum viable process

• Publish/update the return of assets policy and offboarding checklist to include equipment, documents, software, access devices, and credentials ¹.
• Identify systems of record: HR roster, contractor roster, IAM directory, ITAM/CMDB, badge system.
• Implement one standard offboarding ticket template with required fields for each asset category and an exception workflow.
• Run a small back-test: pick recent terminations and confirm you can assemble evidence.

Next 60 days: cover third-party users and close evidence gaps

• Formalize sponsor ownership for contractors and third-party users; require sponsors to initiate offboarding.
• Build an issuance reconciliation step: ensure every laptop/badge/token is tied to a person record.
• Add a documented “non-return” path: lost device handling, legal hold, disputes, and how you document compensating actions.
• Start periodic mismatch checks between active accounts and terminated rosters.

By 90 days: make it repeatable and auditable at scale

• Define metrics you can report without arguing about definitions: open offboarding tickets past due, exceptions outstanding, unmatched active accounts.
• Tighten privileged access offboarding: mandatory secret rotation steps when admins depart.
• Internal audit-ready sampling: keep pre-built evidence packets for a set of recent terminations.
• If you need workflow automation, consider Daydream to centralize offboarding evidence collection (tickets, return logs, IAM exports) and make sampling faster during HITRUST assessments.

Frequently Asked Questions

Does “return of assets” include credentials if credentials aren’t physical items?

Yes. HITRUST explicitly includes “credentials” and “access devices,” so you must treat access enablement as an asset to be recovered (tokens/badges) or revoked (accounts, passwords, MFA) ¹.

How do we handle BYOD where there is no corporate device to return?

Focus on what the person still “has”: corporate data (documents/files) and access (credentials). Your offboarding should include account disablement and confirmation that corporate data is removed or access to synced data is terminated, with documented attestation where needed ¹.

What’s acceptable evidence for “documents” being returned?

A receiving log for physical files works well. If physical return is not feasible, use a signed attestation from the user or sponsor plus documentation of any secure destruction steps your process requires ¹.

Our third party won’t return a hardware token because it’s “theirs.” Are we noncompliant?

You need to distinguish ownership from control intent. If the access device is not returnable, ensure it is disabled and cannot be used to access your systems, then document the exception and disposition ¹.

Do we need a signature from every departing user?

HITRUST requires assets be returned; it does not prescribe a signature format. A signed acknowledgement is strong evidence, but a sponsor attestation plus proof of return/revocation can also support compliance if it’s consistently applied ¹.

What if assets are returned but access revocation lags behind?

That still fails the intent because credentials are explicitly in scope. Make credential revocation a required close criterion for the offboarding ticket, with IAM evidence attached ¹.

Footnotes

1. HITRUST CSF v11 Control Reference